Ryan Hill wrote:
Ryan Hill <[EMAIL PROTECTED]> wrote:
If it's universal, then why isn't it written somewhere? After all
this, we *still* haven't gotten an answer to why some packages
outside of the system target are depending on zlib. Is this a bug? If
not, what's the reason it's there? Let's document this reason, so we
don't have to go through this again in the future. It's that simple.
Hrm, I thought I wrote about this a while ago but I don't see it on
archives.g.o so lets try again.
> If your package is 'not important' meaning it will never be in 'system'
> for any profile, you should not depend on anything in 'system', as
stuff in system should already be installed in a given (sane) configuration.
>
> If your package may be in 'system' in a given profile, you need to
ensure your package builds in the proper order, with regards to other
system packages. The classic example is zlib; if you need zlib to
uncompress something, then you should put zlib in the deps; that way
when someone is building say, a stage1, your package will build after
zlib, instead of before it.
>
> You have to be careful in deciding what to specify, as doing things
incorrectly in this case can often cause dependency loops which are
sometimes fun to debug; perl and openssl were infamous back in the day
for this.
>
> Enterprising users would specify the 'doc' useflag. openssl requires
perl to generate its docs and perl requires openssl for some encryption
stuff. Users would then complain about perl or openssl not building, or
portage getting really pissed at them; the solution being to build
openssl twice, once with USE="-doc" and then build perl, and then
rebuild openssl with USE="doc". This certainly wasn't the only case
where this occurred (see ML thread about shadow and it's dep on some
other package I can't remember, although that was a while back as well).
>
> In conclusion, you need domain knowledge of system packages and
portage behavior to make good choices here ;)
Wow that pasted nastily; hopefully it shows up ok ;)
In any case I'm sure there are some other exceptions but these are the
main ones.
--
gentoo-dev@gentoo.org mailing list
