[gentoo-portage-dev] Slot selection mechanism?

[Daniel Drake]

Hi,

I've been trying to think of ways to get around a dilemma with package versioning.

To use an example, we plan to make gentoo-patched 2.4 and 2.6 kernels 
available under "gentoo-sources" (currently they are split into 2 packages).

At any one time, we'd have a structure like:

gentoo-sources-2.4.27-r1 (stable)
gentoo-sources-2.4.27-r2 (~arch testing)
gentoo-sources-2.6.8-r5 (stable)
gentoo-sources-2.6.9-rc3-r1 (~arch testing)

The problem is that a 2.4 user would see 2.6 as a package update, even though 
they might really want to stick to 2.4. We could get around this by having say 
2.4 as stable, 2.6 as ~arch, but that makes it not possible to release 
"testing" releases for kernels.

So, we'd like a way to allow users to say "I want to stick to 2.4 for kernel 
packages" or something like that. But I don't think this is limited to 
kernels, I think this might be useful in other areas of the tree too?

Take GTK+ (2.4 - the stable branch) as an example. New GTK+ releases first 
come into ~arch for a few weeks, then get moved into stable. I develop GTK+ 
apps, so I use package.keywords to "unmask" these packages.
If the gentoo maintainers decided to put ebuilds for the 2.5 (development) 
branch into the tree, then I'd be asked to upgrade. But thats not what I want, 
not many people like developing for a moving-target API.

So, are there any plans for some sort of slot selection mechanism? One thing 
that I have thought of is some sort of portage application used to do this. 
Something like:

	version-select gtk+ 2.4

I know pretty much nothing about portage internals so I have no idea how 
feasible this sort of idea is. But we (kernel) really would benefit from some 
way to select "slots" like this, without forcing all users having to hack 
/etc/portage for every kernel package they want to use.

Any pointers/comments?

Thanks,
Daniel

--
gentoo-portage-dev@g.o mailing list