Includeonly - was: Re: [Yum] Noarch vs i386

[Carwyn Edwards]

On 7 Nov 2003, at 15:29, Michael Stenner wrote:

> However, if you include
> .pyc files, it is THEY that will be run.  The only value of the .py
> files in this case is so that users can look at them.

On a sort of related note, what's the thinking about /usr/share/yum vs 
/usr/lib/pythonX.X/site-packages. From a users wanting to play/look at 
things point of view putting the ones that can stand as modules in 
their own right in site-packages would be nice. Arch independent stuff 
is supposed to be under /usr/share though.

Are yum and up2date going to remain separate or share more core code in 
future?

On an unrelated note I'm revisiting my includeonly ideas (i.e. being 
able to track _only_ specific packages from fedora development or 
similar. The nasty bit is working out what to do about the packages 
that your includeonly package then depends on - do you pull them from 
the less stable source or your main source (if you have the option). In 
some cases the only option is to pull them from the unstable source, 
this can then have a cascade effect though (say your includeonly needs 
a newer pygtk).

My thinking at the moment is that it's safer to not automatically pull 
down deps from an unstable source and force the user to explicitly list 
them all in includeonly. I think it's safer to fail telling the user 
that they can't have their includeonly without adding all the other 
stuff it needs to.

Is this feature still something people think they would even need with 
the core/testing/development model? I'm assuming so given that debian 
implemented their elaborate package holding system. Personally I'd 
quite like to be able to limit bits of my system to core, have others 
running on testing and try the occasional application or tool from 
development (and track it).

I'm beginning to think that this needs to be merged into the groups 
model to work nicely (i.e. ditching includeonly in the previously 
mentioned sense). For example ..

(I can't remember the comps syntax but you get the idea I hope):

<group name="usual" validsources="ANY">
	...
</group>
<group name="foo" validsources="fedora-core,fedora-testing">
	<rpm name="myrpm"/>
	<rpm name="anotherrpm"/>
</group>
<group name="broken" validsources="fedora-devel">
	<rpm name="bar"/>
	<rpm name="thingy"/>
</group>

.. where fedora-core, fedora-devel etc are sources in yum.conf.

Of course you could argue that this level of flexibility is only really 
useful for "enthusiasts" that are mangling their machines. Most 
production deployments wouldn't want to mix repositories of varying 
stability levels as much.

Hmm, maybe stability/trust level attributes on the repositories would 
work? (kind of like the priorities stuff mentioned): e.g.

[fedora-core]
url=<whatever>
trust-level=1 # stable

<group name="broken" validsources="fedora-devel" deptrustlevel="1">

.. where only packages from repositories with a trust-level <=1 can be 
used to satisfy deps for the group broken.

Thoughts? I'm just opening the can here, the worms aren't out yet :-)

Carwyn