Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: On Fri, 18 Apr 2008 21:45:13 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: I'd go with RDEPEND only. Any other interpretation results in installing build-time-only packages along with a binpkg, which doesn't seem to make sense. That's definitely not what we want. Only a package's DEPENDs have to be installed and usable when that package is built. Its RDEPENDs don't have to be installed until that package is treated as usable. For why this matters: cat/a-1: RDEPEND cat/b cat/b-1: RDEPEND cat/a This is solvable. If package managers can't solve this, they can't install Gnome off a stage 3... I think Donnie (and I) are both looking for concrete examples here. You're claiming GNOME can't be installed so please give us an example with in-tree packages where this breaks. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote:
On Sat, 19 Apr 2008 18:38:06 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
Every package dependency in DEPEND is installed and usable before
src_unpack starts, right? So is the question here whether or not they
can be uninstalled right before pkg_{pre,post}inst starts?
If we're using binaries, DEPEND is usually ignored.
But if we're using binaries then src_unpack isn't called so this is a
moot statement and the O.P.'s statement is correct.
I don't know what the general use of pkg_preinst is, but in
pkg_postinst the package itself should be runnable, so its RDEPENDS
should be installed and usable at this point. So perhaps we should
define that "usable" means "each of its RDEPENDs is installed and has
had its pkg_postinst function run". The recursion of that definition
then comes from the requirement that RDEPENDs should be usable before
pkg_postinst starts running.
No good. That prevents RDEPEND <-> RDEPEND cycles from being solved,
and the package manager has to be able to solve that.
Can you give a concrete example? Not a foo and bar or a and b example.
But a real package example. Because there are a few packages in the tree
which call themselves in pkg_postinst
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Tue, 2008-04-22 at 08:09 +0100, Ciaran McCreesh wrote: > > We definitely don't want to install DEPEND at the pkg_* stages, so I'd > > say the requirement there, if you're asking, is prior to src_*, if > > that matters. > > If the alternatives are not being able to install from a binary at all > due to circular dependencies, or being able to install from a binary > using DEPEND to satisfy circular dependencies, which would you take? Given the trouble that we have every release with trying to cram everything our users want into a limited space, I'd rather the damned thing not install than pull in a bunch of packages we don't need, just to satisfy a dependency that isn't even used during execution of the package. > > I'd love to have some kind of functionality to allow some kind of > > "optional" dependencies. The only real way that I could see this > > working is if we tracked what was installed as an optional dependency, > > and not reinstall it if it has been removed the next time the > > depending package is merged. > > Sort of like what kdebuild has for suggested dependencies, but less > strong? Pretty much, yeah. The main difference that I would see from the current *DEPEND variables, besides what was said above, would be that a lack of visibility wouldn't stop the package merge. If sys-apps/foo had ODEPEND="dev-libs/bar" and dev-libs/bar was masked, it simply wouldn't be installed. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 19 Apr 2008 00:43:08 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > I would agree that RDEPEND should likely be installed prior to > pkg_preinst to satisfy the dependency. After all, PDEPEND is "good > enough" for doing packages that aren't required at > pkg_preinst/pkg_postinst. It's likely to, but not guaranteed to be. > We definitely don't want to install DEPEND at the pkg_* stages, so I'd > say the requirement there, if you're asking, is prior to src_*, if > that matters. If the alternatives are not being able to install from a binary at all due to circular dependencies, or being able to install from a binary using DEPEND to satisfy circular dependencies, which would you take? > I'd love to have some kind of functionality to allow some kind of > "optional" dependencies. The only real way that I could see this > working is if we tracked what was installed as an optional dependency, > and not reinstall it if it has been removed the next time the > depending package is merged. Sort of like what kdebuild has for suggested dependencies, but less strong? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 2008-04-19 at 06:33 +0100, Ciaran McCreesh wrote: > On Fri, 18 Apr 2008 22:27:21 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > My interpretation is pkg_* counts as runtime (I can imagine a package > > wanting to run itself at this point), so packages in RDEPEND should > > be usable at that point. > > Which would be fine, except it makes the tree unusable. > > > Really, it seems to be an additional type of dependency that neither > > DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't > > quite capturing it either. > > Yup, and for future EAPIs labels can fix this. But we have to have a > sound solution for current EAPIs. I would agree that RDEPEND should likely be installed prior to pkg_preinst to satisfy the dependency. After all, PDEPEND is "good enough" for doing packages that aren't required at pkg_preinst/pkg_postinst. We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. I'd love to have some kind of functionality to allow some kind of "optional" dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Simple example: ODEPEND="video_cards_nvidia? ( x11-drivers/nvidia-drivers)" would install x11-drivers/nvidia-drivers the first time it's ran with VIDEO_CARDS="nvidia", but if I removed x11-drivers/nvidia-drivers, it wouldn't get reinstalled. This would probably need some kind of "--newuse" like capability to allow for installing only *new* optional dependencies, but I think that the tracking would already allow that. The idea here would be to allow for installing "recommended" software along with others. We could even have --ask ask for the dependencies, since they are optional, after all. This way, we could "ship" a more robust configuration/setup for many popular applications without forcing software on people. It's an idea, anyway, and I hope that I didn't hijack the thread. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
2008-04-21 12:05 Luca Barbato <[EMAIL PROTECTED]> napisał(a): > Ciaran McCreesh wrote: > > > cat/a-1: RDEPEND cat/b > > cat/b-1: RDEPEND cat/a > > > > This is solvable. If package managers can't solve this, they can't > > install Gnome off a stage 3... > > > > Which are the packages involved in such cycle? Maybe app-admin/gamin and >=dev-libs/glib-2.16[fam].
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Mon, 21 Apr 2008 12:10:53 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > >> Really, it seems to be an additional type of dependency that > >> neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND > >> idea isn't quite capturing it either. > > > > Yup, and for future EAPIs labels can fix this. But we have to have a > > sound solution for current EAPIs. > > Usually I rather see the specific problem before looking for > solutions. The specific problem is that ebuilds currently rely upon the package manager providing circular dependency resolution that works, so we need a good definition of just what's allowed to resolve cycles. But we can't take "what Portage does" as that definition, because Portage's behaviour is "usually get it right by fluke, except when things go horribly wrong". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: Really, it seems to be an additional type of dependency that neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't quite capturing it either. Yup, and for future EAPIs labels can fix this. But we have to have a sound solution for current EAPIs. Usually I rather see the specific problem before looking for solutions. If packages intertwine in strange ways _maybe_ we could work with upstream to fix the insanity at the source instead host it ourselves. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: cat/a-1: RDEPEND cat/b cat/b-1: RDEPEND cat/a This is solvable. If package managers can't solve this, they can't install Gnome off a stage 3... Which are the packages involved in such cycle? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Mon, 21 Apr 2008 10:52:57 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> | cat/a-1 is installed and has RDEPEND cat/b
> | cat/a-2 is to be installed and has DEPEND cat/b and RDEPEND =cat/b-2
> | cat/b-1 is installed and has RDEPEND cat/a
> | cat/b-2 is to be installed and has DEPEND cat/a and RDEPEND =cat/a-2
> |
> | Solve this and enlightenment shall be yours!
> |
> | Or a headache.
>
> This problem has the two obvious solutions: either install a-2 and
> then b-2 or the other way around.
Bzzt, wrong! Once you've installed a-2, you can't install b-2 since it
DEPENDs upon cat/a, but cat/a's run dependencies aren't satisfied, so
the dependency isn't met. And likewise for the other way around.
This problem is nowhere near as simple as you think it is.
> But to be relevant to the current discussion you need to specify
> whether or not there are any pkg_{pre,post}inst functions. If there
> are too many then it becomes unsolvable and is probably a bug, as I
> already explained:
The package manager can't sanely know whether such functions exist. (It
could, theoretically, insanely know, but forcing package managers to
be able to work that out really isn't something we want to do.)
> | Labels are a cleaner solution to this. But again, we're discussing
> | current EAPIs here.
>
> Labels seems to be another syntax for providing the same information
> as I proposed AIUI, i.e. finer-grained deps.
Labels do that and a lot more, and without the explosion in number of
metadata keys. But they're a different discussion.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| On Sun, 20 Apr 2008 22:17:27 -0700
| Donnie Berkholz <[EMAIL PROTECTED]> wrote:
|> I don't think I understand the difference between the effects of
|> these two options.
|
| cat/a-1 is installed and has RDEPEND cat/b
| cat/a-2 is to be installed and has DEPEND cat/b and RDEPEND =cat/b-2
| cat/b-1 is installed and has RDEPEND cat/a
| cat/b-2 is to be installed and has DEPEND cat/a and RDEPEND =cat/a-2
|
| Solve this and enlightenment shall be yours!
|
| Or a headache.
|
This problem has the two obvious solutions: either install a-2 and then b-2 or
the other
way around. But to be relevant to the current discussion you need to specify
whether or
not there are any pkg_{pre,post}inst functions. If there are too many then it
becomes
unsolvable and is probably a bug, as I already explained:
|> If only one of those packages has a pkg_postinst then it is still
|> solvable. If they both have a pkg_postinst then one of those is
|> probably not essential for the actual usability of the package and
|> should be removed. A final possibility is that the pkg_postinsts are
|> both necessary for a fully functional package but not for the
|> functionality used in the other pkg_postinst. If this is the case,
|> then perhaps we should specify deps according to which ebuild phase
|> they are necessary for?
|
| Not with current EAPIs we can't.
|
|> SRC_UNPACK_DEP="app-arch/unzip"
|> SRC_COMPILE_DEP="dev-scheme/bigloo"
|> SRC_INSTALL_DEP=""
|
| Labels are a cleaner solution to this. But again, we're discussing
| current EAPIs here.
Labels seems to be another syntax for providing the same information as I
proposed AIUI,
i.e. finer-grained deps.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sun, 20 Apr 2008 22:17:27 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > I don't think I understand the difference between the effects of > these two options. cat/a-1 is installed and has RDEPEND cat/b cat/a-2 is to be installed and has DEPEND cat/b and RDEPEND =cat/b-2 cat/b-1 is installed and has RDEPEND cat/a cat/b-2 is to be installed and has DEPEND cat/a and RDEPEND =cat/a-2 Solve this and enlightenment shall be yours! Or a headache. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On 06:33 Sat 19 Apr , Ciaran McCreesh wrote: > On Fri, 18 Apr 2008 22:27:21 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > My interpretation is pkg_* counts as runtime (I can imagine a package > > wanting to run itself at this point), so packages in RDEPEND should > > be usable at that point. > > Which would be fine, except it makes the tree unusable. Isn't this part of the first situation offered (RDEPEND+DEPEND, rather than RDEPEND|DEPEND)? I don't think I understand the difference between the effects of these two options. Could you describe a scenario where one would make things possible and the other wouldn't? Here's my attempt from an ebuild dev's POV, not from an ebuild dependency POV: The way I'm thinking, the RDEPEND|DEPEND case means an ebuild developer would have no idea which list would be used, so you'd have something like COMMON_DEPEND to describe the pkg_*-used dependency, which would be in both RDEPEND and DEPEND. This would allow both RDEPEND and DEPEND to have unique dependencies, which seems like it could be beneficial. It would probably require fixing the tree for packages that currently assume RDEPEND will be available, although I don't expect that many packages will have unique RDEPEND settings (mainly binaries). I guess the RDEPEND+DEPEND case would save an ebuild dev the work of specifying the COMMON_DEPEND list, but other than that, I can't think of any benefits. It would force both RDEPEND and DEPEND to be installed for binpkgs, which sucks. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sun, Apr 20, 2008 at 10:36 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sat, 19 Apr 2008 18:29:10 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > > Stop name dropping labels until you tell folk about what labels are. > > I know, but I'd rather not have the notion "labels solves all" pushed > > forth w/ out people knowing what it is, please. > > Labels are already documented and discussable in the appropriate place. > This is not supposed to be a discussion about future direction. It's > supposed to be about one specific issue regarding how we word things for > current implementations. The two wordings in the original email do not > have equivalent implications, and selecting the correct one affects > whether certain problems are solvable. Let's discuss that, not what > we're going to do six years from now. > http://bugs.gentoo.org/show_bug.cgi?id=201499 -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 19 Apr 2008 18:29:10 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > Not all cycles are solvable w/in the domain of execution which is an > unfortunate fact. This loops back into why jstubbs was after use dep > cycle breaking (fair bit more fine grained of an issue), a discussion > that thus far has been ignored, and the usage of the build flag. Which, again, is a future thing, since it requires additional per-ebuild information about how use flags are used to be implementable. > Stop name dropping labels until you tell folk about what labels are. > I know, but I'd rather not have the notion "labels solves all" pushed > forth w/ out people knowing what it is, please. Labels are already documented and discussable in the appropriate place. This is not supposed to be a discussion about future direction. It's supposed to be about one specific issue regarding how we word things for current implementations. The two wordings in the original email do not have equivalent implications, and selecting the correct one affects whether certain problems are solvable. Let's discuss that, not what we're going to do six years from now. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sun, Apr 20, 2008 at 12:57:28AM +0100, Ciaran McCreesh wrote: > On Sat, 19 Apr 2008 18:38:06 +0200 > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote: > > I don't know what the general use of pkg_preinst is, but in > > pkg_postinst the package itself should be runnable, so its RDEPENDS > > should be installed and usable at this point. So perhaps we should > > define that "usable" means "each of its RDEPENDs is installed and has > > had its pkg_postinst function run". The recursion of that definition > > then comes from the requirement that RDEPENDs should be usable before > > pkg_postinst starts running. > > No good. That prevents RDEPEND <-> RDEPEND cycles from being solved, > and the package manager has to be able to solve that. Not all cycles are solvable w/in the domain of execution which is an unfortunate fact. This loops back into why jstubbs was after use dep cycle breaking (fair bit more fine grained of an issue), a discussion that thus far has been ignored, and the usage of the build flag. > > SRC_UNPACK_DEP="app-arch/unzip" > > SRC_COMPILE_DEP="dev-scheme/bigloo" > > SRC_INSTALL_DEP="" > > Labels are a cleaner solution to this. But again, we're discussing > current EAPIs here. Stop name dropping labels until you tell folk about what labels are. I know, but I'd rather not have the notion "labels solves all" pushed forth w/ out people knowing what it is, please. thanks, ~harring pgpm1IpZ6yEzg.pgp Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 19 Apr 2008 18:38:06 +0200
"Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
> Every package dependency in DEPEND is installed and usable before
> src_unpack starts, right? So is the question here whether or not they
> can be uninstalled right before pkg_{pre,post}inst starts?
If we're using binaries, DEPEND is usually ignored.
> I don't know what the general use of pkg_preinst is, but in
> pkg_postinst the package itself should be runnable, so its RDEPENDS
> should be installed and usable at this point. So perhaps we should
> define that "usable" means "each of its RDEPENDs is installed and has
> had its pkg_postinst function run". The recursion of that definition
> then comes from the requirement that RDEPENDs should be usable before
> pkg_postinst starts running.
No good. That prevents RDEPEND <-> RDEPEND cycles from being solved,
and the package manager has to be able to solve that.
> If only one of those packages has a pkg_postinst then it is still
> solvable. If they both have a pkg_postinst then one of those is
> probably not essential for the actual usability of the package and
> should be removed. A final possibility is that the pkg_postinsts are
> both necessary for a fully functional package but not for the
> functionality used in the other pkg_postinst. If this is the case,
> then perhaps we should specify deps according to which ebuild phase
> they are necessary for?
Not with current EAPIs we can't.
> SRC_UNPACK_DEP="app-arch/unzip"
> SRC_COMPILE_DEP="dev-scheme/bigloo"
> SRC_INSTALL_DEP=""
Labels are a cleaner solution to this. But again, we're discussing
current EAPIs here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| I'm rewording the PMS sections on dependencies to avoid permitting
| overly lax circular dependency resolution. Which of these wordings is
| accurate, given that usable means "has its RDEPENDs installed and
| usable"?
|
| 1. During pkg_preinst and pkg_postinst, any package dependency that is
| in both DEPEND and RDEPEND must be installed and usable.
|
| 2. During pkg_preinst and pkg_postinst, at least one of the following
| conditions must be met:
| a. every package dependency in DEPEND must be installed and usable
| b. every package dependency in RDEPEND must be installed and usable
|
| Do not attempt to write on both sides of the paper at once.
Every package dependency in DEPEND is installed and usable before src_unpack
starts,
right? So is the question here whether or not they can be uninstalled right
before
pkg_{pre,post}inst starts?
I don't know what the general use of pkg_preinst is, but in pkg_postinst the
package
itself should be runnable, so its RDEPENDS should be installed and usable at
this point.
So perhaps we should define that "usable" means "each of its RDEPENDs is
installed and has
had its pkg_postinst function run". The recursion of that definition then comes
from the
requirement that RDEPENDs should be usable before pkg_postinst starts running.
| For why this matters:
|
| cat/a-1: RDEPEND cat/b
| cat/b-1: RDEPEND cat/a
|
| This is solvable. If package managers can't solve this, they can't
| install Gnome off a stage 3...
If only one of those packages has a pkg_postinst then it is still solvable.
If they both have a pkg_postinst then one of those is probably not essential
for the
actual usability of the package and should be removed. A final possibility is
that the
pkg_postinsts are both necessary for a fully functional package but not for the
functionality used in the other pkg_postinst. If this is the case, then perhaps
we should
specify deps according to which ebuild phase they are necessary for?
cat/a:
SRC_UNPACK_DEP="app-arch/unzip"
SRC_COMPILE_DEP="dev-scheme/bigloo"
SRC_INSTALL_DEP=""
PKG_PREINST_DEP=""
PKG_POSTINST_DEP="cat/b"
RDEPEND="cat/b"
and then cat/b would say:
PKG_PREINST_DEP=""
PKG_POSTINST_DEP=""
RDEPEND="cat/a"
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Fri, 18 Apr 2008 22:27:21 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > My interpretation is pkg_* counts as runtime (I can imagine a package > wanting to run itself at this point), so packages in RDEPEND should > be usable at that point. Which would be fine, except it makes the tree unusable. > Really, it seems to be an additional type of dependency that neither > DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't > quite capturing it either. Yup, and for future EAPIs labels can fix this. But we have to have a sound solution for current EAPIs. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On 05:54 Sat 19 Apr , Ciaran McCreesh wrote: > On Fri, 18 Apr 2008 21:45:13 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > I'd go with RDEPEND only. Any other interpretation results in > > installing build-time-only packages along with a binpkg, which > > doesn't seem to make sense. > > That's definitely not what we want. Only a package's DEPENDs have to be > installed and usable when that package is built. Its RDEPENDs don't > have to be installed until that package is treated as usable. I previously failed to clarify the situation I preferred because either 1 or 2b qualify as requiring RDEPEND to be installed. My interpretation is pkg_* counts as runtime (I can imagine a package wanting to run itself at this point), so packages in RDEPEND should be usable at that point. Really, it seems to be an additional type of dependency that neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't quite capturing it either. I say this because I wouldn't want everything in DEPEND installed with a binpkg so it can run pkg_*, and I also can see how some people wouldn't consider a package in a runnable state until pkg_* have finished (so thus RDEPEND shouldn't be required). > For why this matters: > > cat/a-1: RDEPEND cat/b > cat/b-1: RDEPEND cat/a > > This is solvable. If package managers can't solve this, they can't > install Gnome off a stage 3... Dealing with this under my interpretation is a bit weird. I think it might need some sort of staging area. That's one reason I mentioned the additional dep type. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Fri, 18 Apr 2008 21:45:13 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > I'd go with RDEPEND only. Any other interpretation results in > installing build-time-only packages along with a binpkg, which > doesn't seem to make sense. That's definitely not what we want. Only a package's DEPENDs have to be installed and usable when that package is built. Its RDEPENDs don't have to be installed until that package is treated as usable. For why this matters: cat/a-1: RDEPEND cat/b cat/b-1: RDEPEND cat/a This is solvable. If package managers can't solve this, they can't install Gnome off a stage 3... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On 05:31 Sat 19 Apr , Ciaran McCreesh wrote: > I'm rewording the PMS sections on dependencies to avoid permitting > overly lax circular dependency resolution. Which of these wordings is > accurate, given that usable means "has its RDEPENDs installed and > usable"? > > 1. During pkg_preinst and pkg_postinst, any package dependency that is > in both DEPEND and RDEPEND must be installed and usable. > > 2. During pkg_preinst and pkg_postinst, at least one of the following > conditions must be met: > a. every package dependency in DEPEND must be installed and usable > b. every package dependency in RDEPEND must be installed and usable I'd go with RDEPEND only. Any other interpretation results in installing build-time-only packages along with a binpkg, which doesn't seem to make sense. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Dependencies that're available at pkg_*inst
I'm rewording the PMS sections on dependencies to avoid permitting overly lax circular dependency resolution. Which of these wordings is accurate, given that usable means "has its RDEPENDs installed and usable"? 1. During pkg_preinst and pkg_postinst, any package dependency that is in both DEPEND and RDEPEND must be installed and usable. 2. During pkg_preinst and pkg_postinst, at least one of the following conditions must be met: a. every package dependency in DEPEND must be installed and usable b. every package dependency in RDEPEND must be installed and usable Do not attempt to write on both sides of the paper at once. -- Ciaran McCreesh signature.asc Description: PGP signature
