From: "Robin H. Johnson" <robbat2@gentoo.org>
To: Gentoo Developers <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Stage1 and dependencies
Date: Sat, 26 Jun 2004 02:52:31 -0700 [thread overview]
Message-ID: <20040626095231.GB7174@curie-int.orbis-terrarum.net> (raw)
In-Reply-To: <200406261827.36325.jstubbs@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 4289 bytes --]
On Sat, Jun 26, 2004 at 06:27:30PM +0900, Jason Stubbs wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 26 June 2004 17:06, Robin H. Johnson wrote:
> > On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote:
> > > Issue #1: Ignoring dependencies
> > > The "cleaning" of the vardb to trick portage is IMO a bad thing. There is
> > > obviously enough in a stage 1 to be able to build up all of system, but
> > > according to the data portage it is impossible. This then requires a hack
> > > as indicated above to attempt the merge anyway. However, this hack
> > > affects users of installed systems as well as portage will go ahead and
> > > attempt a compilation that is guaranteed to fail.
> > What's your solution for this?
> Well, I don't actually understand why the var db needs to be cleaned. I can't
> see why a combination of --nodeps and --onlydeps on package x and y can't
> solve whatever the problem is, though...
Try it and see :-), if you don't see why it shouldn't work, it should
probably work... if not fix it ;-).
> > I've got no objections to putting the correct information into the tree,
> > but portage needs to be able to handle circular dependancies much better
> > first. One other glaring problem in your listing is sys-devel/make. One
> > other thing that will bite at some points is the things that some
> > upstream developers put into their configure scripts, that are decidedly
> > not always present on a system (perl and rpm to name the worst offenders
> > I've seen). If you can tell me I won't run into any problems by adding
> > in the deps for virtual/libc virtual/cc sys-devel/make etc into my
> > packages, I'll go around and correct them now.
> I don't think that the change would bring about any more bad dependency
> ordering than already exists, but I can't be sure. Perhaps, the solution is
> to fix the dependency resolver then fix the packages and then enable parallel
> emerges. That sound acceptable?
Yup, that should be fine. Before .51 comes out, could you maybe add a
bit of code in repoman to detect circular dependancies (and give a
non-fatal warning at the moment), so we can work on them from an early
stage?
I see two cases of circular dependancies that need to be worried about:
- Directly:
pkgA DEPEND on pkgB, and pkgB DEPEND on pkgA - The only solution here
is to code something to work around the circular dependancy, via
bootstrapping one of the packages (similar to getting gcc onto a
machine without a compiler). I know at least one case of this existing
in the tree at a point, but I think it's been fixed at the moment.
- Conditionally directly:
openldap:DEPEND="sasl? ( cyrus-sasl )"
cyrus-sasl:DEPEND="ldap? ( openldap )"
This one is much simpler, just build one of the two without the USE
flag that causes the circular trap. Then build the other package, and
rebuild the first. Hard part would be choosing which one to build
without the USE flag. A few bugs like this exact one exist, see bug
#33440 to track them.
> > virtual/cc is something I think should exist, as some people want to use
> > dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc.
> >
> > Also, where does the adding of dependancies stop? Eg I have something
> > that uses kernel-headers and glibc, so do I just specify glibc and
> > ignore kernel-headers as that's needed by glibc?
> That's a design question that's open to debate. Portage can do it either way,
> but I would suggest that the package depend on both kernel-headers and glibc
> for robustness in the tree. Unlikely in this case, but it ensures that a
> change to glibc's dependencies don't break the packages that depend on it.
Ok, so listing as many dependancies as required (within reason) is
suitable. One other question comes up in your mention of eclasses to
make it easier, namely what's the speed hit going to be with so many
eclasses being added to packages? Won't it be better to change ebuilds
directly?
--
Robin Hugh Johnson
E-Mail : robbat2@orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2004-06-26 10:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-26 6:06 [gentoo-dev] Stage1 and dependencies Jason Stubbs
2004-06-26 8:06 ` Robin H. Johnson
2004-06-26 9:27 ` Jason Stubbs
2004-06-26 9:52 ` Robin H. Johnson [this message]
2004-06-26 12:03 ` Jason Stubbs
2004-06-26 14:01 ` Chris Gianelloni
2004-06-26 14:05 ` Jason Stubbs
2004-06-26 14:45 ` Chris Gianelloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040626095231.GB7174@curie-int.orbis-terrarum.net \
--to=robbat2@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox