FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-19-2008, 04:31 AM
Ciaran McCreesh
 
Default 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
 
Old 04-19-2008, 04:45 AM
Donnie Berkholz
 
Default 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
 
Old 04-19-2008, 04:54 AM
Ciaran McCreesh
 
Default Dependencies that're available at pkg_*inst

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
 
Old 04-19-2008, 05:27 AM
Donnie Berkholz
 
Default 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 <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
 
Old 04-19-2008, 05:33 AM
Ciaran McCreesh
 
Default Dependencies that're available at pkg_*inst

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
 
Old 04-19-2008, 07:43 AM
Chris Gianelloni
 
Default 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 <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
 
Old 04-19-2008, 04:38 PM
"Marijn Schouten (hkBst)"
 
Default 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
<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
 
Old 04-19-2008, 06:53 PM
Duncan
 
Default Dependencies that're available at pkg_*inst

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
 
Old 04-19-2008, 11:55 PM
Ciaran McCreesh
 
Default Dependencies that're available at pkg_*inst

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
 
Old 04-19-2008, 11:57 PM
Ciaran McCreesh
 
Default Dependencies that're available at pkg_*inst

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
 

Thread Tools




All times are GMT. The time now is 06:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org