[Yum] specifying architectures in the grouplist.xml?

Peter C. Norton spacey at lenin.net
Mon Jan 9 16:48:07 UTC 2006


On Tue, Jan 03, 2006 at 05:05:57PM -0500, seth vidal wrote:
> 
> > <group>abi_transition</group>
> >   <required abi_bits=32>package1</required>
> 
> That syntax seems extremely cumbersome.

Well, yes. A more compact form didn't occur to me, but for the sake
of explanation let's call it a placeholder.
 
> > would be less intrusive, since no matter what platformn the name is
> > the same, for those where there is no 64-bit abi the abi_bits would be
> > ignored, and for those that are 64-bit this could be honored by
> > passing a flag to yum to parse on the client side, i.e.  
> > 
> > yum groupinstall abi_transition --abi_bits=32
> 
> adding a flag for this would just confuse the issue, wouldn't it? 

It depends on the implementation of the module. If it's something
specific to the module, then I don't think it would be confusing since
it wouldn't pollute the mainstream code or use or documentation.
 
> In what circumstances would you want ONLY the x86_64 or ONLY the i386
> package installed from a given repository?

My scenarios are as follows:

1) A unified repository for a group that has software to deploy. The
SA is testing switching over, and wants a guarantee that only packages
for the abi being tested will be installed.

2) In production for an application only the x86 version of a library
has been tested and qualified, the x86_64 version has bugs, however
but is present in a production repo because the repository is unified
and so the broken library is there for testing but yum may install it
anyway. So only the x86 version should be deployed but the x86_64
version can be installed as well even though it's broken.

3) By far the most common case IMO, aaaa control freak SA wants a
64-bit only system.

I'm not trying to be too light about this. I'm writing while on
vacation, though, so I'm feeling oddly relaxed.

Thanks for the consideration,

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.




More information about the Yum mailing list