Bernd Steinhauser wrote: > Tiziano Müller schrieb: >> Hi everyone >> >> I'd like to bring bug #229521 to your attention and see whether we can >> come up with a solution for it. >> >> The problem: >> A package "foo" depends on a slotted package "bar" _and_ more than one >> slot of "bar" can satisfy this dependency. >> >> Why this is a problem: >> If the dependency looks like one of the following: >> * DEPEND=">=cat/bar-2" >> * DEPEND="<=cat/bar-3" >> * DEPEND="|| ( cat/bar:2 cat/bar:3 ) >> then the package manager doesn't know after building "foo" which slot of >> "bar" has been used to build "foo". On the other hand might this >> information be needed to debug problems with package "foo". >> >> The problem gets even worse as soon as RDEPEND comes in: >> (assuming the same examples from above but with RDEPEND) >> * The package manager currently doesn't record which slot has been used >> and can't therefore track whether the user will destroy something in >> case he uninstalls one of the slots of "bar" >> * The package manager can't sanely consider whether an update for a slot >> is actually needed > > There is a section in PMS, that tries to address this. > > ================= > Slot Dependencies > A named slot dependency consists of a colon followed by a slot name. A > specification with > a named slot dependency matches only if the slot of the matched package > is equal to the slot > specified. If the slot of the package to match cannot be determined > (e.g. because it is not a > supported EAPI), the match is treated as unsuccessful. > An operator slot dependency consists of a colon followed by one of the > following operators: > * Indicates that any slot value is acceptable. In addition, for runtime > dependencies, indicates > that the package will not break if the matched package is uninstalled > and replaced by a > different matching package in a different slot. > = Indicates that any slot value is acceptable. In addition, for runtime > dependencies, indicates > that the package will break unless a matching package with slot equal to > the slot of the > best installed version at the time the package was installed is available. > To implement the equals slot operator, the package manager will need to > store the slot of the > best installed version of the matching package. The package manager may > do this by appending > the appropriate slot after the equals sign when saving the package?s > dependencies. This syntax > is only for package manager use and must not be used by ebuilds. > ================= > > So, if you go with that, the dependency would look like this: > DEPEND=">=cat/bar-2:=" > > That means, that it accepts any slot of versions above version 2, but > restricts it to the slot it has been built against, at runtime. > The combination of >= and := might look a bit ugly, so maybe it might > indeed be useful to specify a way to provide a list of slots. > But it would work in most cases.
hmm, this is kdebuild-1... I miss two things here: a) What happens in case of DEPEND="", RDEPEND=">=cat/bar-2:=" ? Is that defined? If yes, what does it mean? If not, what shall be the package managers behaviour? b) It is not said that a package depending on "|| ( cat/bar:2 cat/bar:3 )" then really uses cat/bar:3 if available, it might as well use cat/bar:2 for one reason or another. It might be clearer if we have slots named "stable", "unstable". In such a case a package depending on cat/bar might decided to use cat/bar:stable if available instead of cat/bar:unstable. So, the spec should either state that the package must use the best matching version or we need another way for such cases, like a function to explicitly tell the pm which slot has been used. I think that problem a) is a bit nasty, but it might become better if we'd split the dependency variables into DEPEND, RDEPEND, C(OMMON_)DEPEND (where the last one would be used for packages needed at compile time and runtime). -- gentoo-dev@lists.gentoo.org mailing list
