Custom Query (894 matches)
Results (46 - 48 of 894)
| Ticket | Owner | Reporter | Resolution | Summary |
|---|---|---|---|---|
| #50 | desai | bradshaw | fixed | the new initscript client options don't work |
| Description |
here is the problem, and this seems to be a problem for a long time now. the combining of options doesn't work. bcfg2 -qv != bcfg2 -q -v so at the top of the initscript it has BCFG2_OPTIONS="-nq" but that actually doesn't seem to work properly. |
|||
| #51 | desai | [email protected]… | fixed | The bcfg2-server debian sarge package depends on libxml-utils from sid |
| Description |
If you try to install the bcfg2-server package, you get the following error:
|
|||
| #52 | desai | [email protected]… | fixed | Dual arch support |
| Description |
In the infinite wisdom of RHEL, an x86_64 machine produces an interesting obstacle. As you could guess there are x86 and x86_64 versions of some software and libraries. Instead of making these mutually exclusive, RHEL has abused RPM further. Allow me to demonstrate: [[email protected]:~]$ rpm -q e2fsprogs e2fsprogs-1.35-12.3.EL4 e2fsprogs-1.35-12.3.EL4 What you say? Your RPM db must be corrupted. Ah, but it isn't: [[email protected]:~]$ rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\n" e2fsprogs e2fsprogs-1.35-12.3.EL4-x86_64 e2fsprogs-1.35-12.3.EL4-i386 That's right. They've found a way to have RPMs with the same name only differing in the architecture. The RPMs don't have any overlap in what files they provide, though. So here's what's needed. A way to flag an x86_64 package as dual arch so that Bcfg2 will know to install both the x86 and x86_64 package. Logic for Bcfg2 to determine whether or not a dual arch package is installed or not. And I'm sure there's more, but that's all I can think of. Until this functionality is there, bcfg2 can't be used to manage RHEL x86_64 based machines that's why I'm marking this critical. |
|||
