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
