Tiziano Müller schrieb:
Bernd Steinhauser wrote:
Tiziano Müller schrieb:
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...
Indeed, but it is a proposal.
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?
I don't think, that RDEPEND matters here.
If a dep is not in DEPEND, that means, that it doesn't affect the build
process of the package. So in case the dep spec matches more than one
slot, the package should be able to use both without a rebuild.
(Which means, that the package manager can switch the dep.)
If changing the slot would mean, that a rebuild is required, then the
dep affects the package at build time and should be in DEPEND.
Oh, my point is much simpler:
The kdebuild-1 spec says: "[...] 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."
But: RDEPEND doesn't have to be evaluated before installing the package and
DEPEND doesn't contain this package. So, there is no record of such a
package. What now?
tbh, I don't get what you are on about.
The slot restrictions only matter in cases where a rebuild what be
required, because the package would break, if you change the installed
slot. But in that case the dep affects runtime and should be in DEPEND.
For runtime-only deps, the package manager should be allowed to change
the slot, if multiple slots are allowed.
Regarding the || ( cat/bar:2 cat/bar:3 ) construction, if a package
manager chooses one out of the two, it should restrict the package to
this dep at runtime.
Hmm, this is the point: What happens if the package chooses cat/bar:2 to
link against and the package manager records cat/bar:3 since it assumes
this is the better match? Is it it allowed to do the following (it's an
example):
DEPEND="|| ( sys-libs/db:4.5 sys-libs/db:4.6 )"
pkg_setup() {
DB_VER=""
# both major versions work but prefer 4.5 if available
has_version "sys-libs/db:4.5" && DB_VER="4.5"
}
Questions:
a) should DEPEND be valid?
b) will has_version evaluate to true?
c) how will the pm know that the package chose sys-libs/db:4.5
d) should this be allowed or not?
e) if yes, can the package tell the pm about the choice?
That would (in my opinion) a bug in the ebuild.
You handle only the case where db:4.5 is available and not the other case.
Nevertheless, I think what we might need here is something like a reference.
For example, there could be a tag introduced.
||[db] ( sys-libs/db:4.5 sys-libs/db:4.6 )
and then:
if_pulled db[1] && DB_VER="4.5"
if_pulled db[2] && DB_VER="4.6"
Then, if the package manager restricts || ( ) constructions to the
selected dep, you would have a way to ensure, that the correct dep is
installed.
Tbh, the whole "check-if-a-package-(version)-is-installed" thing is a
bit of a hack.
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).
I would rather vote for labels, which clear the whole dependency thing
up a bit and doesn't splatter them over several vars.
Unfortunately that is not compatible with the current way of specifying
deps.
Labels as proposed by kdebuild-1 are only for PDEPEND, right?
Yes, because kdebuild-1 uses the gentoo way of specifying deps (DEPEND,
RDEPEND etc.).
But labels in general aren't restricted to PDEPEND.
Actually labels (if fully implemented) obsolete DEPEND, RDEPEND etc.
See https://bugs.gentoo.org/show_bug.cgi?id=201499#c21 for an example.
The result is, that it is better readable and gives more possibilities.
--
gentoo-dev@lists.gentoo.org mailing list
