Mailing List Archive

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

On Fri, 18 Apr 2008 21:45:13 -0700
Donnie Berkholz <dberkholz@gentoo.org> 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

On 05:54 Sat 19 Apr , Ciaran McCreesh wrote:
> On Fri, 18 Apr 2008 21:45:13 -0700
> Donnie Berkholz <dberkholz@gentoo.org> 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

On Fri, 18 Apr 2008 22:27:21 -0700
Donnie Berkholz <dberkholz@gentoo.org> 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

On Sat, 2008-04-19 at 06:33 +0100, Ciaran McCreesh wrote:
> On Fri, 18 Apr 2008 22:27:21 -0700
> Donnie Berkholz <dberkholz@gentoo.org> 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

-----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
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgKH+4ACgkQp/VmCx0OL2xJOwCfdEO5IhWbjPvFRidzgdyFanEd
0v4An26a2XJ9Y4hwDz/bpqeUWeDMXAuk
=v/UL
-----END PGP SIGNATURE-----
--
gentoo-dev@lists.gentoo.org mailing list

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20080419063300.6d2a2525@snowcone, excerpted below, on Sat, 19 Apr 2008
06:33:00 +0100:

> On Fri, 18 Apr 2008 22:27:21 -0700
> Donnie Berkholz <dberkholz@gentoo.org> 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.

It seems to me that at least for current EAPIs, RDEPEND simply cannot be
depended upon during pkg_*inst without breaking things. I can't see a
way around that.

About the least-bad of multiple bad solutions I can see for Donnie's
conceivable run scenario would be to print a message in pkg_postinst
telling the user to run emerge --config before running the program
normally, maybe even going to the point of renaming the runtime and
installing a fake that reminds folks to run emerge --config first, if
it's critical enough. (pkg_config would then kill the fake and rename
the runtime back to its proper name.)

Now consider binary packages. DEPEND can't be used as-is, which in the
OR case would then mandate RDEPEND and again result in broken behavior
due to circular dependencies, so that simply doesn't work. That leaves
the intersection of both DEPEND and RDEPEND sets as the only possible
logically consistent resolution...

UNLESS we either (1) accept that binary package behavior simply can't be
correctly defined under current EAPIs and declare it an indeterminate
legacy exception, or (2) declare binary packages an exception that works
by different rules, and then define them (somehow). Either alternative
would then leave somewhat more flexibility for the ordinary build case,
presumably enough to reasonably accurately describe current behavior
deterministically. (I'll freely admit to not knowing enough about
current tree behavior to pick the right option there.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@lists.gentoo.org mailing list

On Sat, 19 Apr 2008 18:53:27 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> It seems to me that at least for current EAPIs, RDEPEND simply cannot
> be depended upon during pkg_*inst without breaking things. I can't
> see a way around that.

But DEPEND can't either.

The point is, one of the two wordings in the original email is enough.
In fact, both are, but they have different implications, and selecting
the right one is important.

--
Ciaran McCreesh

On Sat, 19 Apr 2008 18:38:06 +0200
"Marijn Schouten (hkBst)" <hkBst@gentoo.org> 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

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)" <hkBst@gentoo.org> 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

On Sat, 19 Apr 2008 18:29:10 -0700
Brian Harring <ferringb@gmail.com> 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

On Sun, Apr 20, 2008 at 10:36 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 19 Apr 2008 18:29:10 -0700
> Brian Harring <ferringb@gmail.com> 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: cooldwind@gmail.com
--
gentoo-dev@lists.gentoo.org mailing list

On 06:33 Sat 19 Apr , Ciaran McCreesh wrote:
> On Fri, 18 Apr 2008 22:27:21 -0700
> Donnie Berkholz <dberkholz@gentoo.org> 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

On Sun, 20 Apr 2008 22:17:27 -0700
Donnie Berkholz <dberkholz@gentoo.org> 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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
| On Sun, 20 Apr 2008 22:17:27 -0700
| Donnie Berkholz <dberkholz@gentoo.org> 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
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgMVekACgkQp/VmCx0OL2waMgCglvtOPnu1xBIpUn0EbG7jDNsf
xLQAoLfQR4s8hAvzhgfx5JuY4sj9gp7+
=Creb
-----END PGP SIGNATURE-----
--
gentoo-dev@lists.gentoo.org mailing list

On Mon, 21 Apr 2008 10:52:57 +0200
"Marijn Schouten (hkBst)" <hkBst@gentoo.org> 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

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

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

On Mon, 21 Apr 2008 12:10:53 +0200
Luca Barbato <lu_zero@gentoo.org> 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

2008-04-21 12:05 Luca Barbato <lu_zero@gentoo.org> 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].
z{h¡×¯–+-²§¶Š(® šŠX§‚X¬

Donnie Berkholz <dberkholz@gentoo.org> posted
20080421051727.GA10765@comet, excerpted below, on Sun, 20 Apr 2008
22:17:27 -0700:

> 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.

If I read the original proposal correctly, it's not proposing a simple +,
that BOTH RDEPEND and DEPEND be guaranteed installed at pkg_*inst, IOW by
set theory, not the UNION of the two sets, but the INTERSECTION of the
two sets, that is, packages that appear in both lists at once, not those
appearing in one XOR the other.

Thus a COMMON_DEPEND would still be useful as it would be the list
appearing in both (thus effectively the list necessary for pkg_*inst,
same as the OR case). Both lists could still exclusively include
packages, and packages not listed in DEPEND only would not have to be
installed for binpkgs.

So it's not OR vs AND, but OR vs INTERSECTION.

As I stated in my other post, RDEPEND alone can't be used without
breaking things. That applies to binary package installation as well,
where DEPEND along can't be used either as that would require
installation of unwanted packages. Thus, the OR case doesn't seem to
work for binary installation at all, since neither RDEPEND nor DEPEND can
be relied upon alone, and the OR case proposes requiring at least one
complete set of the two be installed.

Thus, for current EAPIs, the INTERSECTION alternative is the only
possibly working alternative if we are not to break binary package
support and not force full DEPEND installation on binary targets. It's
not ideal as it'll potentially force unwanted and otherwise unnecessary
package installation on both the build-host and the binary target, due to
fact that it forces pkg_*inst dependencies into both DEPEND and RDEPEND,
but IMO it's better than forcing the whole set of DEPENDs to be installed
on binary targets, which would be the only working alternative in the OR
case above.

As others have said, this is certainly a good candidate for future EAPI
change, but it's not future EAPIs under current discussion, so that fact
doesn't help the current discussion.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@lists.gentoo.org mailing list

On Sat, 19 Apr 2008 00:43:08 -0700
Chris Gianelloni <wolf31o2@gentoo.org> 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

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

Ciaran McCreesh wrote:
> On Sat, 19 Apr 2008 18:38:06 +0200
> "Marijn Schouten (hkBst)" <hkBst@gentoo.org> 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