Custom Query (894 matches)
Results (70 - 72 of 894)
| Ticket | Owner | Reporter | Resolution | Summary |
|---|---|---|---|---|
| #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. |
|||
| #54 | desai | [email protected]… | fixed | Validation |
| Description |
This validates in groups.xml: <Group name='base'>
<Group name='bcfg-daily' category='bcfg-control'/>
...
</Group>
<Group name='batch'>
<Group name='bcfg-byhand' category='bcfg-control'/>
<Group name='base'/>
...
</Group>
|
|||
