[gentoo-portage-dev] [RFC] Depending on active version
Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. Currently this isn't really possible, however I while ago I got an idea how to solve this. Keep in mind this is just a rough idea and I'm pretty sure some people can/will point out why it is a stupid idea, but anyway: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied (and yes, this kinda goes with multi-repo/multi-format support) Marius -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Tue, Jan 30, 2007 at 05:06:51PM +0100, Marius Mauch wrote: Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. tr1 is partially addressed via addition of a 'binding' modifier for rdeps, to state that ||() deps are locked down after compilation. Doesn't gurantee the user doesn't pop back to 3.4 after compilation, but that's their own mess. The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Non deterministic resolution; previous steps in the graph can cause that value to flip to a different setting by the time the 'dep' is encountered. That's ignoring the kick in the nads usage of this will due to resolution... (and yes, this kinda goes with multi-repo/multi-format support) Don't really see how this enables multiple standalone repos in any sane way, so that one requires justification... ~harring pgpetWeCOF0tF.pgp Description: PGP signature
Re: [gentoo-portage-dev] [RFC] Depending on active version
Marius Mauch wrote: Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. Currently this isn't really possible, however I while ago I got an idea how to solve this. Keep in mind this is just a rough idea and I'm pretty sure some people can/will point out why it is a stupid idea, but anyway: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied (and yes, this kinda goes with multi-repo/multi-format support) Marius I don't see why how this is any less complicated than just adding more functionality to || deps (runtime versus compile time) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Tue, 30 Jan 2007 08:25:31 -0800 Brian Harring [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2007 at 05:06:51PM +0100, Marius Mauch wrote: Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. tr1 is partially addressed via addition of a 'binding' modifier for rdeps, to state that ||() deps are locked down after compilation. And how would that solve the actual issue of expressing I need /usr/bin/gcc to run gcc-4.1 and not gcc-3.4? The lockdown of || deps is a completely separate issue, unless I'm missing something. The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Non deterministic resolution; previous steps in the graph can cause that value to flip to a different setting by the time the 'dep' is encountered. Ok, that's a problem, though for the use cases at hand (gcc and kernel) it would be mostly irrelevant. That's ignoring the kick in the nads usage of this will due to resolution... Neglectable IMO, it's not such a common use case anyway, and I don't think I have to compare it to the current solution (die in setup or compile). (and yes, this kinda goes with multi-repo/multi-format support) Don't really see how this enables multiple standalone repos in any sane way, so that one requires justification... Where did I say anything about enabling? It would need more or less a separate repository (dbapi) instance, so it would require such support. Marius -- gentoo-portage-dev@gentoo.org mailing list
