[gentoo-dev] Dependencies on sys-apps/portage

[gentoo-dev] Dependencies on sys-apps/portage

[Stephen Bennett]

There are a lot of packages in the tree which DEPEND on some version of
sys-apps/portage, mostly for historical reasons. Try to avoid doing
this in your packages where possible -- if it's a genuine dependency
then obviously it should be there, but if the dep is only in the ebuild
to avoid hitting a bug that was in portage-2.0.49-r3 (for example),
it's unnecessary now. I'm going to be removing some of these redundant
deps.

On which note, the current base profile specifies portage-2.0.51.22 or
later -- can anyone see a reason not to require 2.1? There are a lot of
packages that dep on portage-2.1 for the "wrong" reasons above, which
I'd like to be able to clean up.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Dependencies on system packages

[Stephen Bennett]

And, on a more general note, don't bother depending on a package listed
in base/packages. It's pointless and just create more noise.


On Sun, 10 Dec 2006 01:11:17 +0000
Stephen Bennett <spb@gentoo.org> wrote:

> There are a lot of packages in the tree which DEPEND on some version
> of sys-apps/portage, mostly for historical reasons. Try to avoid doing
> this in your packages where possible -- if it's a genuine dependency
> then obviously it should be there, but if the dep is only in the
> ebuild to avoid hitting a bug that was in portage-2.0.49-r3 (for
> example), it's unnecessary now. I'm going to be removing some of
> these redundant deps.
> 
> On which note, the current base profile specifies portage-2.0.51.22 or
> later -- can anyone see a reason not to require 2.1? There are a lot
> of packages that dep on portage-2.1 for the "wrong" reasons above,
> which I'd like to be able to clean up.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Dependencies on system packages

[Piotr Jaroszyński]

> And, on a more general note, don't bother depending on a package listed
> in base/packages. It's pointless and just create more noise.

It's seems to be needed sometimes b/c it does change the order of generated 
deplist(emerge -e world). AFAIK some packages dep on zlib b/c of that.

-- 
Best Regards,
Piotr Jaroszyński

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Sun, 10 Dec 2006 03:22:52 +0100 Piotr Jaroszyński <peper@gentoo.org>
wrote:
| > And, on a more general note, don't bother depending on a package
| > listed in base/packages. It's pointless and just create more noise.
| 
| It's seems to be needed sometimes b/c it does change the order of
| generated deplist(emerge -e world). AFAIK some packages dep on zlib
| b/c of that.

It's necessary for some system packages, yes. In general, unless your
package is likely to be included in part of system, there's no need to
specify system dependencies.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Dependencies on system packages

[Piotr Jaroszyński]

> It's necessary for some system packages, yes. In general, unless your
> package is likely to be included in part of system, there's no need to
> specify system dependencies.

Have a look at equery d zlib and e.g. bug #151708

-- 
Best Regards,
Piotr Jaroszyński

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Dependencies on system packages

[Stephen Bennett]

On Sun, 10 Dec 2006 03:22:52 +0100
Piotr Jaroszyński <peper@gentoo.org> wrote:

> It's seems to be needed sometimes b/c it does change the order of
> generated deplist(emerge -e world). AFAIK some packages dep on zlib
> b/c of that.

If you don't know about the unwritten yet near universal exception
clause then you shouldn't be invoking it.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Dependencies on system packages

[Steve Long]

Stephen Bennett wrote:
>> It's seems to be needed sometimes b/c it does change the order of
>> generated deplist(emerge -e world). AFAIK some packages dep on zlib
>> b/c of that.
> 
> If you don't know about the unwritten yet near universal exception
> clause then you shouldn't be invoking it.
> 
Could you spell out that exception clause, please?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on system packages

[Stephen Bennett]

On Mon, 11 Dec 2006 11:03:18 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> Could you spell out that exception clause, please?

It doesn't translate well into words, but we'll go with something like
"Unless you know exactly why the rule is there, understand fully the imp
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on system packages

[Stephen Bennett]

On Mon, 11 Dec 2006 11:35:34 +0000
Stephen Bennett <spb@gentoo.org> wrote:

> On Mon, 11 Dec 2006 11:03:18 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> 
> > Could you spell out that exception clause, please?
> 
> It doesn't translate well into words, but we'll go with something like
> "Unless you know exactly why the rule is there, understand fully the
> imp

My mail client, touchpad, and right hand are retarded. That should read:

"understand fully the implications of breaking it, and know why it's a
good idea in this particular case."

However, if you're in a position to be invoking that clause, you should
know about it anyway.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Dependencies on system packages

[Steve Long]

Stephen Bennett wrote:
> Steve Long wrote:
>> Could you spell out that exception clause, please?
> It doesn't translate well into words, but we'll go with something like
> "Unless you know exactly why the rule is there, understand fully the
> implications of breaking it, and know why it's a 
> good idea in this particular case."
> 
> However, if you're in a position to be invoking that clause, you should
> know about it anyway.

OK; the rule, AFAICT, is don't depend on an app that's in base profile. This
includes portage. There seemed to be probs with /not/ depending on zlib
tho?

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Dependencies on system packages

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

Stephen Bennett <spb@gentoo.org> wrote:

> > Could you spell out that exception clause, please?
> 
> It doesn't translate well into words, but we'll go with something
> like "Unless you know exactly why the rule is there, understand
> fully the implications of breaking it, and know why it's a
> good idea in this particular case."
> 
> However, if you're in a position to be invoking that clause, you
> should know about it anyway.

Can we skip the sekrit rulez crap and just spell it out?  Really, how
does this help anyone?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <dirtyepic@gentoo.org>
wrote:
| Stephen Bennett <spb@gentoo.org> wrote:
| > > Could you spell out that exception clause, please?
| > 
| > It doesn't translate well into words, but we'll go with something
| > like "Unless you know exactly why the rule is there, understand
| > fully the implications of breaking it, and know why it's a
| > good idea in this particular case."
| > 
| > However, if you're in a position to be invoking that clause, you
| > should know about it anyway.
| 
| Can we skip the sekrit rulez crap and just spell it out?  Really, how
| does this help anyone?

It's quite simple. You don't do it unless you are fully aware of the
consequences. If you have to ask, you aren't fully aware of the
consequences so you mustn't do it.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Dependencies on system packages

[Doug Goldstein]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

Ciaran McCreesh wrote:
> On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <dirtyepic@gentoo.org>
> wrote:
> | Stephen Bennett <spb@gentoo.org> wrote:
> | > > Could you spell out that exception clause, please?
> | > 
> | > It doesn't translate well into words, but we'll go with something
> | > like "Unless you know exactly why the rule is there, understand
> | > fully the implications of breaking it, and know why it's a
> | > good idea in this particular case."
> | > 
> | > However, if you're in a position to be invoking that clause, you
> | > should know about it anyway.
> | 
> | Can we skip the sekrit rulez crap and just spell it out?  Really, how
> | does this help anyone?
> 
> It's quite simple. You don't do it unless you are fully aware of the
> consequences. If you have to ask, you aren't fully aware of the
> consequences so you mustn't do it.
> 

Which clearly doesn't answer Ryan's question... but hey... that's a
Ciaran answer...

Basically the idea is that Ciaran and spb can protect their image as the
all knowing gods of programming. In other mailing lists they would be
considered trolls and/or Debian devs/users.

-- 
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: Dependencies on system packages

[Mike Doty]

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

Doug Goldstein wrote:
> Ciaran McCreesh wrote:
>> On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <dirtyepic@gentoo.org>
>> wrote:
>> | Stephen Bennett <spb@gentoo.org> wrote:
>> | > > Could you spell out that exception clause, please?
>> | > 
>> | > It doesn't translate well into words, but we'll go with something
>> | > like "Unless you know exactly why the rule is there, understand
>> | > fully the implications of breaking it, and know why it's a
>> | > good idea in this particular case."
>> | > 
>> | > However, if you're in a position to be invoking that clause, you
>> | > should know about it anyway.
>> | 
>> | Can we skip the sekrit rulez crap and just spell it out?  Really, how
>> | does this help anyone?
>>
>> It's quite simple. You don't do it unless you are fully aware of the
>> consequences. If you have to ask, you aren't fully aware of the
>> consequences so you mustn't do it.
>>
> 
> Which clearly doesn't answer Ryan's question... but hey... that's a
> Ciaran answer...
> 
> Basically the idea is that Ciaran and spb can protect their image as the
> all knowing gods of programming. In other mailing lists they would be
> considered trolls and/or Debian devs/users.
> 
All right, all the trolling needs to stop.  Please direct your flames at
the closest brick wall.

- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo/AMD64 Strategic Lead
Gentoo Council
Gentoo Developer Relations
Gentoo Recruitment Lead
Gentoo Infrastructure
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRYSDAIBrouQZ9K4FAQI1SAP/eIuXRpqypo8wdbtfISgmhtbMICczjl1d
aZrALxsATSWnmQjy7E9E2B2A7iFKQxIyCKXlUusoDtTooGmBegXALZzgQ7oOL3gt
YJFcP0YjFTLnwfpfwauVMfYJGB/ClmGze0nVNyGfU2dSt4eWY9zLw9Ai90v2jGPX
U0B+VjlnLpY=
=f/Mj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Sat, 16 Dec 2006 15:21:36 -0500 Doug Goldstein <cardoe@gentoo.org>
wrote:
| > It's quite simple. You don't do it unless you are fully aware of the
| > consequences. If you have to ask, you aren't fully aware of the
| > consequences so you mustn't do it.
| > 
| 
| Which clearly doesn't answer Ryan's question... but hey... that's a
| Ciaran answer...

No, it answers it perfectly, and far better than the other answers in
this thread that give an incomplete and inaccurate perspective that
will encourage people to do the wrong thing.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Dependencies on system packages

[Alec Warner]

Ciaran McCreesh wrote:
> On Sat, 16 Dec 2006 15:21:36 -0500 Doug Goldstein <cardoe@gentoo.org>
> wrote:
> | > It's quite simple. You don't do it unless you are fully aware of the
> | > consequences. If you have to ask, you aren't fully aware of the
> | > consequences so you mustn't do it.
> | > 
> | 
> | Which clearly doesn't answer Ryan's question... but hey... that's a
> | Ciaran answer...
> 
> No, it answers it perfectly, and far better than the other answers in
> this thread that give an incomplete and inaccurate perspective that
> will encourage people to do the wrong thing.
> 

Some people learn by making mistakes ;)
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Dependencies on system packages

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Ciaran McCreesh <ciaranm@ciaranm.org> wrote:

> On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <dirtyepic@gentoo.org>
> wrote:

> | Can we skip the sekrit rulez crap and just spell it out?  Really,
> | how does this help anyone?
> 
> It's quite simple. You don't do it unless you are fully aware of the
> consequences. If you have to ask, you aren't fully aware of the
> consequences so you mustn't do it.

That's a flawed argument.  Not knowing doesn't prevent you from asking,
and asking will inform you of the consequences, assuming the asked
isn't a complete tool.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Dependencies on system packages

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Ryan Hill <dirtyepic@gentoo.org> wrote:

> Ciaran McCreesh <ciaranm@ciaranm.org> wrote:

> > It's quite simple. You don't do it unless you are fully aware of the
> > consequences. If you have to ask, you aren't fully aware of the
> > consequences so you mustn't do it.
> 
> That's a flawed argument.  Not knowing doesn't prevent you from
> asking, and asking will inform you of the consequences, assuming the
> asked isn't a complete tool.

Let me try this more diplomatically.  How are we supposed to know if a
package that's depending on a system package is a bug or an exception if
we have no idea what the exception(s) is/are?

Stephen Bennett wrote:
> If you don't know about the unwritten yet near universal exception
> clause then you shouldn't be invoking it.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Dependencies on system packages

[Alec Warner]

Ryan Hill wrote:
> Ryan Hill <dirtyepic@gentoo.org> 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

[gentoo-dev] Re: Dependencies on system packages

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

Alec Warner <antarus@gentoo.org> wrote:

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

Cool, that's exactly what I was looking for.

thanks ;d

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Dependencies on system packages

[Steve Long]

Ryan Hill wrote:
> Cool, that's exactly what I was looking for.
> 
> thanks ;d

Yeah me too, thanks for a straight reply! ;)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on system packages

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]

On Sunday 17 December 2006 10:27, Alec Warner wrote:
> 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.

Except if the package is fussy on what version it needs.

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

Given your point above, this should only be important as far as bootstrapping
goes. After bootstrapping, "stuff in system should already be installed".
However, 'system' becomes quite an extensive list of packages after enabling
all use flags that didn't begin with 'no'. I've attached the list that
results from my current tree. So are packages such as qt, nvidia-drivers,
courier-imap, samba and jack-audio-connection-kit also part of 'system' or
is 'system' only limited to the profile-defined USE flags at the time of
bootstrapping?

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

This stopped applying with recent versions of portage. I'm pretty sure the
current stable version of portage detects circular deps and tries to resolve
them utilizing installed packages but I've lost track of what's made it to
stable and what hasn't. As far as I know, both palidus and pkgcore do or will
also support this, so your point here doesn't hold.

> Enterprising users would specify the 'doc' useflag. openssl requires perl
> to generate its docs and perl requires openssl for some encryption stuff.
[snipped]

This example is not a reason to leave out appropriate dependencies.

I've tried to be objective here so if my viewpoint isn't obvious I'll state
it outright. I think all packages should depend on every package that they
need to build and/or run. Whether this is done explicitly or with
meta-packages, I don't really care. The only reason for not being explicit
with deps is to cater for old sloppy versions of portage. Unless there are
other reasons not stated here?

--
Jason Stubbs

[-- Attachment #2: sys-pkgs --]
[-- Type: text/plain, Size: 11250 bytes --]

app-admin/eselect-1.0.2
app-admin/eselect-esd-20060719
app-admin/eselect-opengl-1.0.3
app-admin/gamin-0.1.7
app-admin/perl-cleaner-1.04.3
app-admin/php-toolkit-1.0-r2
app-admin/skey-1.1.5-r5
app-admin/syslog-ng-1.6.9
app-arch/bzip2-1.0.3-r6
app-arch/cpio-2.6-r5
app-arch/gzip-1.3.5-r10
app-arch/rpm-4.4.6-r3
app-arch/rpm2targz-9.0-r5
app-arch/tar-1.16-r2
app-arch/unzip-5.52-r1
app-crypt/gnupg-1.4.6
app-crypt/gnupg-1.9.21
app-crypt/hashalot-0.3-r2
app-crypt/kth-krb-1.2.2-r2
app-crypt/mhash-0.9.2
app-crypt/mit-krb5-1.4.3-r3
app-crypt/opencdk-0.5.5
app-doc/doxygen-1.4.7
app-doc/opengl-manpages-20001215
app-doc/php-docs-20050822
app-editors/emacs-21.4-r4
app-misc/ca-certificates-20050804
app-misc/mime-types-5
app-misc/pax-utils-0.1.13
app-portage/portage-manpages-20060913
app-portage/portage-utils-0.1.20
app-shells/bash-3.1_p17
app-text/aspell-0.50.5-r4
app-text/build-docbook-catalog-1.2
app-text/docbook-dsssl-stylesheets-1.79
app-text/docbook-sgml-dtd-3.0-r3
app-text/docbook-sgml-dtd-3.1-r3
app-text/docbook-sgml-dtd-4.0-r3
app-text/docbook-sgml-dtd-4.1-r3
app-text/docbook-sgml-dtd-4.2-r2
app-text/docbook-sgml-utils-0.6.14
app-text/docbook-xml-dtd-4.1.2-r6
app-text/docbook-xml-dtd-4.2-r1
app-text/docbook-xml-simple-dtd-1.0-r1
app-text/docbook-xml-simple-dtd-4.1.2.4-r2
app-text/docbook-xsl-stylesheets-1.68.1-r1
app-text/ghostscript-gpl-8.54
app-text/htmltidy-4.8.6
app-text/jadetex-3.13-r1
app-text/libpaper-1.1.20
app-text/openjade-1.3.2-r1
app-text/opensp-1.5.2-r1
app-text/poppler-0.5.3
app-text/recode-3.6-r2
app-text/rman-3.2
app-text/scrollkeeper-0.3.14-r2
app-text/sgml-common-0.6.3-r4
app-text/tetex-3.0_p1-r3
app-text/xmlto-0.0.18
dev-db/cdb-0.75-r1
dev-db/firebird-1.5.3-r1
dev-db/freetds-0.62.3
dev-db/libiodbc-3.51.2
dev-db/libpq-8.0.8
dev-db/mysql-5.0.26-r1
dev-db/postgresql-8.0.8
dev-db/qdbm-1.8.70-r1
dev-db/qt-unixODBC-3.3.6
dev-db/sqlite-2.8.16-r4
dev-db/sqlite-3.3.5-r1
dev-db/unixODBC-2.2.11-r1
dev-dotnet/libgdiplus-1.1.13.2
dev-java/blackdown-jdk-1.4.2.03-r12
dev-java/java-config-1.3.7
dev-java/java-config-2.0.30
dev-java/java-config-wrapper-0.12-r1
dev-java/java-sdk-docs-1.4.2
dev-java/java-sdk-docs-1.5.0-r1
dev-java/sun-jce-bin-1.5.0
dev-java/sun-jdk-1.5.0.08
dev-lang/lua-5.0.2
dev-lang/mono-1.1.13.8.1
dev-lang/ocaml-3.09.2
dev-lang/perl-5.8.8-r2
dev-lang/php-5.1.6-r6
dev-lang/python-2.4.3-r4
dev-lang/ruby-1.8.5_p2
dev-lang/swig-1.3.25
dev-lang/tcl-8.4.9
dev-lang/tk-8.4.9
dev-libs/DirectFB-0.9.25.1
dev-libs/apr-0.9.12
dev-libs/apr-util-0.9.12
dev-libs/atk-1.12.1
dev-libs/beecrypt-3.1.0-r2
dev-libs/cgilib-0.5
dev-libs/check-0.9.3-r1
dev-libs/cyrus-sasl-2.1.22-r1
dev-libs/elfutils-0.118
dev-libs/expat-1.95.8
dev-libs/glib-2.12.4-r1
dev-libs/gmp-4.2.1
dev-libs/libassuan-0.6.10
dev-libs/libedit-20050930
dev-libs/libgcrypt-1.2.2-r1
dev-libs/libgpg-error-1.0-r1
dev-libs/libksba-0.9.15
dev-libs/libmcrypt-2.5.7
dev-libs/libol-0.3.17
dev-libs/libpcre-6.6
dev-libs/libtasn1-0.3.5
dev-libs/libusb-0.1.11
dev-libs/libxml2-2.6.26
dev-libs/libxslt-1.1.17
dev-libs/lzo-2.02-r1
dev-libs/mm-1.3.0
dev-libs/mpfr-2.2.0_p10
dev-libs/opensc-0.10.1
dev-libs/openssl-0.9.8d
dev-libs/popt-1.7-r1
dev-libs/pth-2.0.3
dev-libs/yaz-2.1.8-r1
dev-libs/zziplib-0.13.45
dev-perl/DBD-mysql-3.0007
dev-perl/DBI-1.52
dev-perl/Locale-gettext-1.05
dev-perl/Net-Daemon-0.39
dev-perl/PlRPC-0.2018
dev-perl/SGMLSpm-1.03-r5
dev-perl/XML-Parser-2.34
dev-perl/perl-tk-804.027
dev-php5/pecl-mcve-5.2.0
dev-php5/pecl-pdo-1.0.2
dev-php5/pecl-pdo-dblib-1.0
dev-php5/pecl-pdo-mysql-1.0.1
dev-php5/pecl-pdo-oci-1.0
dev-php5/pecl-pdo-odbc-1.0
dev-php5/pecl-pdo-pgsql-1.0.1
dev-php5/pecl-pdo-sqlite-1.0
dev-php5/pecl-yaz-1.0.4
dev-php5/pecl-zip-1.0
dev-php5/php-java-bridge-2.0.8
dev-python/docutils-0.3.7
dev-python/egenix-mx-base-2.0.5
dev-python/pycrypto-2.0.1-r5
dev-python/pyrex-0.9.4.1
dev-python/python-fchksum-1.7.1
dev-python/sancho-0.11-r1
dev-ruby/ruby-config-0.3.1
dev-tcltk/expect-5.42.1-r1
dev-util/dejagnu-1.4.4-r1
dev-util/dialog-1.0.20050206
dev-util/gtk-doc-1.6-r1
dev-util/guile-1.6.7
dev-util/intltool-0.35.0
dev-util/monodoc-1.1.13
dev-util/pkgconfig-0.20
dev-util/re2c-0.10.4
dev-util/scons-0.96.1
kde-base/arts-3.5.5
mail-mta/postfix-2.2.10
media-fonts/arphicfonts-0.1-r2
media-fonts/baekmuk-fonts-2.2
media-fonts/encodings-1.0.0
media-fonts/font-adobe-100dpi-1.0.0
media-fonts/font-adobe-75dpi-1.0.0
media-fonts/font-alias-1.0.1
media-fonts/font-cursor-misc-1.0.0
media-fonts/font-misc-misc-1.0.0
media-fonts/font-util-1.0.1
media-fonts/gnu-gs-fonts-std-8.11
media-fonts/kochi-substitute-20030809-r3
media-gfx/graphviz-2.8-r2
media-gfx/xloadimage-4.1-r4
media-libs/a52dec-0.7.4-r5
media-libs/aalib-1.4_rc5
media-libs/alsa-lib-1.0.13
media-libs/audiofile-0.2.6-r2
media-libs/fontconfig-2.3.2-r1
media-libs/freeglut-2.4.0
media-libs/freetype-2.1.10-r2
media-libs/gd-2.0.33
media-libs/giflib-4.1.4
media-libs/glitz-0.5.6
media-libs/imlib2-1.3.0
media-libs/jasper-1.701.0
media-libs/jbigkit-1.6-r1
media-libs/jpeg-6b-r7
media-libs/lcms-1.14-r1
media-libs/libart_lgpl-2.3.17
media-libs/libcaca-0.9-r2
media-libs/libggi-2.1.1
media-libs/libgii-0.9.0
media-libs/libid3tag-0.15.1b
media-libs/libmad-0.15.1b
media-libs/libmng-1.0.9-r1
media-libs/libmpeg3-1.5.2-r3
media-libs/libogg-1.1.2
media-libs/libpng-1.2.13
media-libs/libsdl-1.2.11
media-libs/libsndfile-1.0.11
media-libs/libsvg-0.1.2
media-libs/libvorbis-1.1.0
media-libs/mesa-6.5.1-r1
media-libs/ming-0.2a
media-libs/nas-1.7-r1
media-libs/portaudio-18.1-r5
media-libs/t1lib-5.0.2
media-libs/tiff-3.8.2-r2
media-libs/urt-3.1b-r1
media-sound/alsa-headers-1.0.13
media-sound/esound-0.2.36-r2
media-sound/jack-audio-connection-kit-0.101.1-r1
net-analyzer/net-snmp-5.2.1.2-r1
net-analyzer/rrdtool-1.2.6-r1
net-dns/c-ares-1.3.0
net-dns/libidn-0.5.15
net-fs/samba-3.0.22-r3
net-libs/c-client-2004a-r1
net-libs/courier-authlib-0.58
net-libs/gnutls-1.4.4-r1
net-libs/libmonetra-5.2
net-libs/libwww-5.4.0-r7
net-libs/openslp-1.2.1
net-mail/courier-imap-4.0.4
net-mail/mailbase-1
net-mail/mailwrapper-0.2.1
net-misc/curl-7.15.1-r1
net-misc/iputils-021109-r3
net-misc/neon-0.26.1-r1
net-misc/openssh-4.4_p1-r6
net-misc/rsync-2.6.8-r2
net-misc/wget-1.10.2
net-nds/openldap-2.3.27-r3
net-print/cups-1.2.6
net-print/foomatic-db-ppds-20060720
net-print/foomatic-filters-3.0.20060720
net-print/foomatic-filters-ppds-20060720
net-proxy/dante-1.1.19
net-www/apache-2.0.58-r2
perl-core/Sys-Syslog-0.18
perl-core/Test-Simple-0.64
sci-libs/djbfft-0.76
sys-apps/acl-2.2.34
sys-apps/attr-2.4.28-r1
sys-apps/baselayout-1.12.6
sys-apps/busybox-1.2.2.1
sys-apps/coreutils-6.4
sys-apps/dbus-0.62-r1
sys-apps/debianutils-2.15-r1
sys-apps/diffutils-2.8.7-r1
sys-apps/ed-0.2-r6
sys-apps/file-4.17-r1
sys-apps/findutils-4.3.0
sys-apps/gawk-3.1.5-r2
sys-apps/grep-2.5.1-r8
sys-apps/groff-1.19.2-r1
sys-apps/hdparm-6.6
sys-apps/help2man-1.36.4
sys-apps/hotplug-base-20040401
sys-apps/kbd-1.12-r8
sys-apps/less-394
sys-apps/lm_sensors-2.10.0
sys-apps/man-1.6d
sys-apps/man-pages-2.42
sys-apps/module-init-tools-3.2.2-r1
sys-apps/net-tools-1.60-r12
sys-apps/pcsc-lite-1.3.1-r1
sys-apps/portage-2.1.1-r2
sys-apps/sandbox-1.2.17
sys-apps/sed-4.1.5
sys-apps/setarch-1.8
sys-apps/shadow-4.0.18.1
sys-apps/sysvinit-2.86-r5
sys-apps/tcp-wrappers-7.6-r8
sys-apps/texinfo-4.8-r5
sys-apps/util-linux-2.12r-r4
sys-apps/which-2.16
sys-apps/xinetd-2.3.14
sys-devel/autoconf-2.13
sys-devel/autoconf-2.60
sys-devel/autoconf-wrapper-3.2-r2
sys-devel/autogen-5.7.1
sys-devel/automake-1.5
sys-devel/automake-1.6.3
sys-devel/automake-1.7.9-r1
sys-devel/automake-1.8.5-r3
sys-devel/automake-1.9.6-r2
sys-devel/automake-wrapper-2-r1
sys-devel/bc-1.06-r6
sys-devel/binutils-2.16.1-r3
sys-devel/binutils-config-1.9-r3
sys-devel/bison-2.2
sys-devel/flex-2.5.33-r1
sys-devel/gcc-4.1.1-r1
sys-devel/gcc-config-1.3.13-r4
sys-devel/gettext-0.15
sys-devel/gnuconfig-20060702
sys-devel/libperl-5.8.8-r1
sys-devel/libtool-1.5.22
sys-devel/m4-1.4.6
sys-devel/make-3.81
sys-devel/patch-2.5.9
sys-fs/e2fsprogs-1.39
sys-fs/sysfsutils-1.3.0-r1
sys-fs/udev-087-r1
sys-kernel/linux-headers-2.6.11-r2
sys-kernel/vanilla-sources-2.6.16.19
sys-libs/com_err-1.39
sys-libs/cracklib-2.8.9-r1
sys-libs/db-1.85-r2
sys-libs/db-3.2.9-r11
sys-libs/db-4.2.52_p4-r2
sys-libs/gdbm-1.8.3-r2
sys-libs/glibc-2.4-r4
sys-libs/gpm-1.20.1-r5
sys-libs/libcap-1.10-r5
sys-libs/libutempter-1.1.4.1
sys-libs/ncurses-5.5-r3
sys-libs/pam-0.78-r3
sys-libs/pwdb-0.62
sys-libs/readline-5.1_p4
sys-libs/slang-1.4.9-r2
sys-libs/ss-1.39
sys-libs/timezone-data-2006p
sys-libs/zlib-1.2.3-r1
sys-process/procps-3.2.6
sys-process/psmisc-22.2
virtual/ghostscript-0
virtual/glu-7.0
virtual/glut-1.0
virtual/jdk-1.4.2
virtual/jdk-1.5.0
virtual/jre-1.5.0
virtual/libiconv-0
virtual/libintl-0
virtual/mysql-5.0
virtual/opengl-7.0
virtual/perl-Storable-2.15
virtual/perl-Test-Simple-0.64
virtual/xft-7.0
www-client/lynx-2.8.6-r1
x11-apps/bdftopcf-1.0.0
x11-apps/iceauth-1.0.1
x11-apps/luit-1.0.1
x11-apps/mkfontdir-1.0.2
x11-apps/mkfontscale-1.0.1
x11-apps/rgb-1.0.1
x11-apps/xauth-1.0.1
x11-apps/xinit-1.0.2-r6
x11-apps/xkbcomp-1.0.2
x11-apps/xplsprinters-1.0.1
x11-apps/xprop-1.0.1
x11-base/xorg-server-1.1.1-r1
x11-drivers/nvidia-drivers-1.0.8776
x11-drivers/xf86-input-keyboard-1.1.0
x11-drivers/xf86-input-mouse-1.1.1
x11-libs/Xaw3d-1.5-r1
x11-libs/cairo-1.2.4
x11-libs/gtk+-2.10.6
x11-libs/lesstif-0.94.4
x11-libs/libICE-1.0.1
x11-libs/libSM-1.0.1
x11-libs/libX11-1.0.3
x11-libs/libXTrap-1.0.0
x11-libs/libXau-1.0.2
x11-libs/libXaw-1.0.2
x11-libs/libXcursor-1.1.7
x11-libs/libXdmcp-1.0.1
x11-libs/libXext-1.0.1
x11-libs/libXfixes-4.0.1
x11-libs/libXfont-1.2.2
x11-libs/libXft-2.1.10
x11-libs/libXi-1.0.1
x11-libs/libXinerama-1.0.1
x11-libs/libXmu-1.0.2
x11-libs/libXp-1.0.0
x11-libs/libXpm-3.5.5
x11-libs/libXprintUtil-1.0.1
x11-libs/libXrandr-1.1.1
x11-libs/libXrender-0.9.1
x11-libs/libXres-1.0.1
x11-libs/libXt-1.0.2
x11-libs/libXtst-1.0.1
x11-libs/libXxf86dga-1.0.1
x11-libs/libXxf86misc-1.0.1
x11-libs/libXxf86vm-1.0.1
x11-libs/libdmx-1.0.2
x11-libs/libdrm-2.0.2
x11-libs/libfontenc-1.0.2
x11-libs/liblbxutil-1.0.1
x11-libs/libsvg-cairo-0.1.6
x11-libs/libxkbfile-1.0.3
x11-libs/libxkbui-1.0.2
x11-libs/motif-config-0.9
x11-libs/pango-1.14.9
x11-libs/qt-3.3.6-r4
x11-libs/qt-4.1.4-r2
x11-libs/xtrans-1.0.1
x11-misc/gccmakedep-1.0.2
x11-misc/imake-1.0.2
x11-misc/makedepend-1.0.0
x11-misc/shared-mime-info-0.17-r2
x11-misc/util-macros-1.1.0
x11-misc/xbitmaps-1.0.1
x11-misc/xdg-utils-1.0
x11-misc/xkeyboard-config-0.8
x11-misc/xorg-cf-files-1.0.2
x11-proto/bigreqsproto-1.0.2
x11-proto/compositeproto-0.3.1
x11-proto/damageproto-1.0.3
x11-proto/dmxproto-2.2.2
x11-proto/evieext-1.0.2
x11-proto/fixesproto-4.0
x11-proto/fontcacheproto-0.1.2
x11-proto/fontsproto-2.0.2
x11-proto/glproto-1.4.8
x11-proto/inputproto-1.3.2
x11-proto/kbproto-1.0.3
x11-proto/printproto-1.0.3
x11-proto/randrproto-1.1.2
x11-proto/recordproto-1.13.2
x11-proto/renderproto-0.9.2
x11-proto/resourceproto-1.0.2
x11-proto/scrnsaverproto-1.1.0
x11-proto/trapproto-3.4.3
x11-proto/videoproto-2.2.2
x11-proto/xcmiscproto-1.1.2
x11-proto/xextproto-7.0.2
x11-proto/xf86bigfontproto-1.1.2
x11-proto/xf86dgaproto-2.0.2
x11-proto/xf86driproto-2.0.3
x11-proto/xf86miscproto-0.9.2
x11-proto/xf86rushproto-1.1.2
x11-proto/xf86vidmodeproto-2.2.2
x11-proto/xineramaproto-1.1.2
x11-proto/xproto-7.0.7
x11-terms/xterm-222

Re: [gentoo-dev] Re: Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| I've tried to be objective here so if my viewpoint isn't obvious I'll
| state it outright. I think all packages should depend on every
| package that they need to build and/or run. Whether this is done
| explicitly or with meta-packages, I don't really care. The only
| reason for not being explicit with deps is to cater for old sloppy
| versions of portage. Unless there are other reasons not stated here?

If you mandate that, any package using autotools will need around fifty
new entries in DEPEND.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Dependencies on system packages

[Jason Stubbs]

On Sunday 17 December 2006 16:04, Ciaran McCreesh wrote:
> On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs <jstubbs@gentoo.org>
> wrote:
> | I've tried to be objective here so if my viewpoint isn't obvious I'll
> | state it outright. I think all packages should depend on every
> | package that they need to build and/or run. Whether this is done
> | explicitly or with meta-packages, I don't really care. The only
> | reason for not being explicit with deps is to cater for old sloppy
> | versions of portage. Unless there are other reasons not stated here?
>
> If you mandate that, any package using autotools will need around fifty
> new entries in DEPEND.

There's ways to manage this complexity, such as putting the dependencies into 
autotools' RDEPEND (if it can be considered correct) or by using 
meta-packages. However, your point is against requiring that packages _must_ 
specify all system dependencies. While I personally believe that packages 
should specify all dependencies, what I'm arguing against is requiring that 
packages _must not_ specify any system dependencies.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Sun, 17 Dec 2006 16:41:40 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| On Sunday 17 December 2006 16:04, Ciaran McCreesh wrote:
| > On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs <jstubbs@gentoo.org>
| > wrote:
| > | I've tried to be objective here so if my viewpoint isn't obvious
| > | I'll state it outright. I think all packages should depend on
| > | every package that they need to build and/or run. Whether this is
| > | done explicitly or with meta-packages, I don't really care. The
| > | only reason for not being explicit with deps is to cater for old
| > | sloppy versions of portage. Unless there are other reasons not
| > | stated here?
| >
| > If you mandate that, any package using autotools will need around
| > fifty new entries in DEPEND.
| 
| There's ways to manage this complexity, such as putting the
| dependencies into autotools' RDEPEND (if it can be considered
| correct)

That one pulls us back into the lack of distinction between "stuff
needed when compiling against this library" and "stuff this library
needs to run".

| or by using meta-packages.

DEPEND="virtual/c-toolchain" would indeed be nice, but it's a rather
large change...

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Dependencies on system packages

[Steve Long]

Ciaran McCreesh wrote:
> That one pulls us back into the lack of distinction between "stuff
> needed when compiling against this library" and "stuff this library
> needs to run".
> 
Wouldn't your c-toolchain or a compiler eg for PERL or Java do?

> | or by using meta-packages.
> 
> DEPEND="virtual/c-toolchain" would indeed be nice, but it's a rather
> large change...
> 
How so? Isn't it simply a new meta?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On Mon, 18 Dec 2006 07:28:25 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| Ciaran McCreesh wrote:
| > That one pulls us back into the lack of distinction between "stuff
| > needed when compiling against this library" and "stuff this library
| > needs to run".
| 
| Wouldn't your c-toolchain or a compiler eg for PERL or Java do?

You're missing the distinction. The easy example, but not the best, is
pkg-config: many libraries must be used via pkg-config, so they need to
RDEPEND upon it to avoid breaking binary packages. However, they don't
actually require it at runtime. The other option, which is just about
doable in this one particular case, is to make any package that uses a
library that uses pkg-config DEPEND upon pkg-config.

| > | or by using meta-packages.
| > 
| > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a rather
| > large change...
| > 
| How so? Isn't it simply a new meta?

And an entire tree to update before it becomes meaningful.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Re: Dependencies on system packages

[Steve Long]

Ciaran McCreesh wrote:
> On Mon, 18 Dec 2006 07:28:25 +0000 Steve Long wrote:
> | Ciaran McCreesh wrote:
> | > That one pulls us back into the lack of distinction between "stuff
> | > needed when compiling against this library" and "stuff this library
> | > needs to run".
> | 
> | Wouldn't your c-toolchain or a compiler eg for PERL or Java do?
> 
> You're missing the distinction. The easy example, but not the best, is
> pkg-config: many libraries must be used via pkg-config, so they need to
> RDEPEND upon it to avoid breaking binary packages. However, they don't
> actually require it at runtime. The other option, which is just about
> doable in this one particular case, is to make any package that uses a
> library that uses pkg-config DEPEND upon pkg-config.
> 
What do you mean by "stuff needed when compiling against this library"? I'm
not understanding what distinction you're trying to make- a reverse-compile
dep? I can understand compile-time dependencies and run-time dependencies.
You seem to be talking about the compile-time dependency of any pkg
compiling against a library. Doh! I see what you mean, that isn't the same;
so effectively there's another type of dep.

How serious an issue is it in terms of deps on sys pkgs?

> | > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a rather
> | > large change...
> | > 
> | How so? Isn't it simply a new meta?
> 
> And an entire tree to update before it becomes meaningful.
> 
Sure, but the changes can propagate thru as people update their ebuilds, no?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Wed, 20 Dec 2006 04:59:58 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| How serious an issue is it in terms of deps on sys pkgs?

Very. It means we can't realistically handle packages that, by using
autotools, depend upon the fifty odd system packages that are used by
autotools-generated code.

| > | > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a
| > | > rather large change...
| > | > 
| > | How so? Isn't it simply a new meta?
| > 
| > And an entire tree to update before it becomes meaningful.
| > 
| Sure, but the changes can propagate thru as people update their
| ebuilds, no?

The tricky part then is figuring out whether something doesn't dep upon
c-compiler because it doesn't need one or because the ebuilds haven't
been updated.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Re: Re: Dependencies on system packages

[Steve Long]

Ciaran McCreesh wrote:
> Steve Long wrote:
> | How serious an issue is it in terms of deps on sys pkgs?
> 
> Very. It means we can't realistically handle packages that, by using
> autotools, depend upon the fifty odd system packages that are used by
> autotools-generated code.
> 
> | > | > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a
> | > | > rather large change...
> | > | > 
> | > | How so? Isn't it simply a new meta?
> | > 
> | > And an entire tree to update before it becomes meaningful.
> | > 
> | Sure, but the changes can propagate thru as people update their
> | ebuilds, no?
> 
> The tricky part then is figuring out whether something doesn't dep upon
> c-compiler because it doesn't need one or because the ebuilds haven't
> been updated.
> 
I'm out of my depth here- I can't see where that would be a problem?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Dependencies on system packages

[Alec Warner]

Steve Long wrote:
> Ciaran McCreesh wrote:
>> Steve Long wrote:
>> | How serious an issue is it in terms of deps on sys pkgs?
>>
>> Very. It means we can't realistically handle packages that, by using
>> autotools, depend upon the fifty odd system packages that are used by
>> autotools-generated code.
>>
>> | > | > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a
>> | > | > rather large change...
>> | > | > 
>> | > | How so? Isn't it simply a new meta?
>> | > 
>> | > And an entire tree to update before it becomes meaningful.
>> | > 
>> | Sure, but the changes can propagate thru as people update their
>> | ebuilds, no?
>>
>> The tricky part then is figuring out whether something doesn't dep upon
>> c-compiler because it doesn't need one or because the ebuilds haven't
>> been updated.
>>
> I'm out of my depth here- I can't see where that would be a problem?
> 

Er, his point being that if you don't do the upgrade all at once, you 
have two classes of package.

1. Packages that don't require C-compiler
2. Packages that don't yet depend upon C-compiler

When doing the upgrade over a period of time the two classes of package 
become indistinguishable.  Does Foo not need a C compiler, or has it 
just not gotten updated yet, it's impossible to tell without looking, so 
it's very difficult for people to report 'problem packages' because they 
have to unpack and examine the package every time (at worst).

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: Re: Re: Dependencies on system packages

[Steve Long]

Alec Warner wrote:
>>> The tricky part then is figuring out whether something doesn't dep upon
>>> c-compiler because it doesn't need one or because the ebuilds haven't
>>> been updated.
>>>
>> I'm out of my depth here- I can't see where that would be a problem?
>> 
> 
> Er, his point being that if you don't do the upgrade all at once, you
> have two classes of package.
> 
> 1. Packages that don't require C-compiler
> 2. Packages that don't yet depend upon C-compiler
> 
> When doing the upgrade over a period of time the two classes of package
> become indistinguishable.  Does Foo not need a C compiler, or has it
> just not gotten updated yet, it's impossible to tell without looking, so
> it's very difficult for people to report 'problem packages' because they
> have to unpack and examine the package every time (at worst).
> 
I understand that there'd be two types of pkg in the tree; what I don't get
is why that is such a problem. Excuse my missing something obvious. What do
you mean by a `problem package' in this context?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Dependencies on system packages

[Robert Buchholz]

Steve Long wrote:
> Alec Warner wrote:
>> Er, his point being that if you don't do the upgrade all at once, you
>> have two classes of package.
>>
>> 1. Packages that don't require C-compiler
>> 2. Packages that don't yet depend upon C-compiler
>>
>> When doing the upgrade over a period of time the two classes of package
>> become indistinguishable.  Does Foo not need a C compiler, or has it
>> just not gotten updated yet, it's impossible to tell without looking, so
>> it's very difficult for people to report 'problem packages' because they
>> have to unpack and examine the package every time (at worst).
>>
> I understand that there'd be two types of pkg in the tree; what I don't get
> is why that is such a problem. Excuse my missing something obvious. What do
> you mean by a `problem package' in this context?

A problem package would be one that does not need a C compiler. It can't
be distinguished from the one which was not yet changed to depend on C.

The problem here is that one can not say when the whole tree is updated
to the new standard, because for the packages which were not touched, it
could mean that they needed no change or that they were not looked at yet.

A solution to distinguish the two categories is to mark the packages
which were "checked", so you know:
1. If it's checked and doesn't depend on cc -> category 1
2. If it's not checked and doesn't depend on cc -> category 2

Then, when all packages are checked, the tree is upgraded.

Regards,

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

[gentoo-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages

[Steve Long]

Robert Buchholz wrote:
> A problem package would be one that does not need a C compiler. It can't
> be distinguished from the one which was not yet changed to depend on C.
> 
> The problem here is that one can not say when the whole tree is updated
> to the new standard, because for the packages which were not touched, it
> could mean that they needed no change or that they were not looked at yet.
>
I can understand that as a maintenance issue. My query is whether having two
different types of pkg would effect users in any way.

> A solution to distinguish the two categories is to mark the packages
> which were "checked", so you know:
> 1. If it's checked and doesn't depend on cc -> category 1
> 2. If it's not checked and doesn't depend on cc -> category 2
> 
> Then, when all packages are checked, the tree is upgraded.
> 
Sure, that makes sense. It sounds a heckuva lot like a database ;)

Minor point- how can you tell in cat 2 that it definitely does not need a C
compiler if it hasn't been checked? I'm guessing you were tired :) In any
event in terms of maintenance, we'd need a tri-state: unchecked, checked
and needs compiling, checked and doesn't (eg scripts).

In terms of maintaining the metadata, am I right in thinking it's all just
kept within the text files in the tree?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages

[Robert Buchholz]

Steve Long wrote:
> Robert Buchholz wrote:
>> The problem here is that one can not say when the whole tree is updated
>> to the new standard, because for the packages which were not touched, it
>> could mean that they needed no change or that they were not looked at yet.
> I can understand that as a maintenance issue. My query is whether having two
> different types of pkg would effect users in any way.

You're right, it would not be a problem for usability.


>> A solution to distinguish the two categories is to mark the packages
>> which were "checked", so you know:
>> 1. If it's checked and doesn't depend on cc -> category 1
>> 2. If it's not checked and doesn't depend on cc -> category 2
>>
>> Then, when all packages are checked, the tree is upgraded.
>>
> Sure, that makes sense. It sounds a heckuva lot like a database ;)
> 
> Minor point- how can you tell in cat 2 that it definitely does not need a C
> compiler if it hasn't been checked? I'm guessing you were tired :) In any
> event in terms of maintenance, we'd need a tri-state: unchecked, checked
> and needs compiling, checked and doesn't (eg scripts).

No, no. I did not mean that "category 2" does not need a C compiler. I
referred to Alec's mail which had "2. Packages that don't yet depend
upon C-compiler".
As for the state problem, when saving "checked" and "unchecked" as a
package's metadata, you will get the other properties (needs cc, needs
<insert system dep>) out of its DEPEND.


> In terms of maintaining the metadata, am I right in thinking it's all just
> kept within the text files in the tree?

Since the tree itself is the best database of the packages available,
anything else would be a lot more overhead.

But I had the impression the idea was discarded anyway. So I should
focus my thoughts somewhere else :-)


Ciao,

Robert

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: Re: Re: Re: Re: Dependencies on system packages

[Steve Long]

Robert Buchholz wrote:
> Steve Long wrote:
>> Robert Buchholz wrote:
>>> The problem here is that one can not say when the whole tree is updated
>>> to the new standard, because for the packages which were not touched, it
>>> could mean that they needed no change or that they were not looked at
>>> yet.
>> I can understand that as a maintenance issue. My query is whether having
>> two different types of pkg would effect users in any way.
> 
> You're right, it would not be a problem for usability.
>
Well that makes a change ;) Although it sounds like a maintenance nightmare.

> 
>>> A solution to distinguish the two categories is to mark the packages
>>> which were "checked", so you know:
>>> 1. If it's checked and doesn't depend on cc -> category 1
>>> 2. If it's not checked and doesn't depend on cc -> category 2
>>>
>>> Then, when all packages are checked, the tree is upgraded.
>>>
>> Sure, that makes sense. It sounds a heckuva lot like a database ;)
>> 
>> Minor point- how can you tell in cat 2 that it definitely does not need a
>> C compiler if it hasn't been checked? I'm guessing you were tired :) In
>> any event in terms of maintenance, we'd need a tri-state: unchecked,
>> checked and needs compiling, checked and doesn't (eg scripts).
> 
> No, no. I did not mean that "category 2" does not need a C compiler. I
> referred to Alec's mail which had "2. Packages that don't yet depend
> upon C-compiler".
> As for the state problem, when saving "checked" and "unchecked" as a
> package's metadata, you will get the other properties (needs cc, needs
> <insert system dep>) out of its DEPEND.
>
Alec Warner wrote:
> 1. Packages that don't require C-compiler
> 2. Packages that don't yet depend upon C-compiler
> 
> When doing the upgrade over a period of time the two classes of package
> become indistinguishable.  Does Foo not need a C compiler, or has it
> just not gotten updated yet, it's impossible to tell without looking, so
> it's very difficult for people to report 'problem packages' because they
> have to unpack and examine the package every time (at worst).
> 
I understand that it's hard to distinguish a pkg that hasn't been checked,
but might need the C-compiler, from a pkg that doesn't need the compiler
but just hasn't been checked. That's where I was going with the database
stuff.

> 
>> In terms of maintaining the metadata, am I right in thinking it's all
>> just kept within the text files in the tree?
> 
> Since the tree itself is the best database of the packages available,
> anything else would be a lot more overhead.
> 
I really don't agree, altho I could well be missing something. Surely there
should be a maintenance/QA database which tracks the tree and where you
could put information like this (ie a boolean flag for this instance) which
simply shouldn't be exposed to users. There's no need for it, it doesn't
effect them, and why should it go in the ebuilds where a maintainer might
delete it?

> But I had the impression the idea was discarded anyway. So I should
> focus my thoughts somewhere else :-)
> 
Please focus your thoughts wherever you wish. I gotta ask tho; what idea? I
thought we were just talking about excess dependencies in the tree.

May your thoughts be pleasant :)


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: metadatabase (was: Dependencies on system packages)

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

Steve Long wrote:
> Robert Buchholz wrote:

> I understand that it's hard to distinguish a pkg that hasn't been checked,
> but might need the C-compiler, from a pkg that doesn't need the compiler
> but just hasn't been checked. That's where I was going with the database
> stuff.

>> Since the tree itself is the best database of the packages available,
>> anything else would be a lot more overhead.

> I really don't agree, altho I could well be missing something. Surely there
> should be a maintenance/QA database which tracks the tree and where you
> could put information like this (ie a boolean flag for this instance) which
> simply shouldn't be exposed to users. There's no need for it, it doesn't
> effect them, and why should it go in the ebuilds where a maintainer might
> delete it?

I just use a local db to keep track of stuff like this, but haven't
thought of a way to turn this into a service and i don't think it's
really doable.  I think you'd need an entry for every ebuild in portage,
times the number of archs, times an unlimited number of arbitrary fields
(one for each thing you're tracking).  Something like, say, checking
every package in the tree for GPL-2 or GPL-2+ licenses doesn't need the
separate arch entries of course, but stuff like GCC testing definitely does.

Even if you did manage to set this up, I wouldn't want to maintain it.


--
                                        by design, by neglect
dirtyepic gentoo org            for a fact or just for effect
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: metadatabase

[Robert Buchholz]

Ryan Hill wrote:
> Steve Long wrote:
>> Robert Buchholz wrote:
>>> Since the tree itself is the best database of the packages available,
>>> anything else would be a lot more overhead.
> 
>> I really don't agree, altho I could well be missing something. Surely there
>> should be a maintenance/QA database which tracks the tree and where you
>> could put information like this (ie a boolean flag for this instance) which
>> simply shouldn't be exposed to users. There's no need for it, it doesn't
>> effect them, and why should it go in the ebuilds where a maintainer might
>> delete it?
> 
> I just use a local db to keep track of stuff like this, but haven't
> thought of a way to turn this into a service and i don't think it's
> really doable.  I think you'd need an entry for every ebuild in portage,
> times the number of archs, times an unlimited number of arbitrary fields
> (one for each thing you're tracking).  Something like, say, checking
> every package in the tree for GPL-2 or GPL-2+ licenses doesn't need the
> separate arch entries of course, but stuff like GCC testing definitely does.
> 
> Even if you did manage to set this up, I wouldn't want to maintain it.

I don't want to sound negative and I like the idea a lot, but two things
are on my mind about this:

It should also sync with changes in the tree, like package removals,
additions and package moves.

When you're talking about it on ebuild base: When a version bump is out,
will it inherit the flags of the version before?


Regards,

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

[gentoo-dev] Re: metadatabase

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Robert Buchholz wrote:

> I don't want to sound negative and I like the idea a lot, but two things
> are on my mind about this:
> 
> It should also sync with changes in the tree, like package removals,
> additions and package moves.

For sure.

> When you're talking about it on ebuild base: When a version bump is out,
> will it inherit the flags of the version before?

I'd say no.  The flags could easily change from version to version, even
from revbump to revbump.  For example, a bump could introduce some kind
of QA violation not present in the previous ebuild or fail 'make test'
where the last version worked.  Depends on what you're tracking I guess.


-- 
                                        by design, by neglect
dirtyepic gentoo org            for a fact or just for effect
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: metadatabase

[Steve Long]

Ryan Hill wrote:
> Robert Buchholz wrote:
>> I don't want to sound negative and I like the idea a lot, but two things
>> are on my mind about this:
>> 
>> It should also sync with changes in the tree, like package removals,
>> additions and package moves.
> 
> For sure.
> 
>> When you're talking about it on ebuild base: When a version bump is out,
>> will it inherit the flags of the version before?
> 
> I'd say no.  The flags could easily change from version to version, even
> from revbump to revbump.  For example, a bump could introduce some kind
> of QA violation not present in the previous ebuild or fail 'make test'
> where the last version worked.  Depends on what you're tracking I guess.
> 
++ to both, but I'm not an expert on ebuilds or the tree.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: metadatabase (was: Dependencies on system packages)

[Steve Long]

Ryan Hill wrote:
> I just use a local db to keep track of stuff like this, but haven't
> thought of a way to turn this into a service and i don't think it's
> really doable.  I think you'd need an entry for every ebuild in portage,
> times the number of archs, times an unlimited number of arbitrary fields
> (one for each thing you're tracking).  Something like, say, checking
> every package in the tree for GPL-2 or GPL-2+ licenses doesn't need the
> separate arch entries of course, but stuff like GCC testing definitely
> does.
>
Agreed. Let's say 15000 ebuilds * 10 architectures or 150000 records of
actual instances of ebuilds. These could be linked to a table of pkg names,
so the first 3 tables and example uses that spring to mind are:

Pkg=> tracking of requires CC
Pkg-version=> ebuild maintenance
Pkg-version-arch=> bugs

It still doesn't strike me as an unfeasible amount of data for any of the
standard db servers. The custom bit would be code to keep it synced to the
portage tree, which doesn't strike me as all that hard. We could simply
capture the rsync output to see the changes for a start.

TBH I have no idea how useful such a db would be, I just find it an
interesting project.

> Even if you did manage to set this up, I wouldn't want to maintain it.
> 
No fair enough, nor would I! All I'm up for maintaining is the automation
side, not the individual pkgs.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: Dependencies on system packages

[Robert Buchholz]

Steve Long schrieb:
>>> In terms of maintaining the metadata, am I right in thinking it's all
>>> just kept within the text files in the tree?
>> Since the tree itself is the best database of the packages available,
>> anything else would be a lot more overhead.
>>
> I really don't agree, altho I could well be missing something. Surely there
> should be a maintenance/QA database which tracks the tree and where you
> could put information like this (ie a boolean flag for this instance) which
> simply shouldn't be exposed to users. There's no need for it, it doesn't
> effect them, and why should it go in the ebuilds where a maintainer might
> delete it?

You are totally right. Though there's one little effect: Before someone
files a bug because the package does not depend on a CC, (s)he will have
to know whether it's already checked. But if the DB is public, that's
not an issue.


>> But I had the impression the idea was discarded anyway. So I should
>> focus my thoughts somewhere else :-)
> Please focus your thoughts wherever you wish. I gotta ask tho; what idea? I
> thought we were just talking about excess dependencies in the tree.

I somehow lost track of the messages in this thread, but the idea of
having large scale dependencies any system package needed seemed not
realistically doable.
If it's just about adding virtual/c-toolchain, was there arguments
against it?

Regards,

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

[gentoo-dev] Re: Re: Re: Re: Re: Re: Re: Re: Dependencies on system packages

[Steve Long]

Robert Buchholz wrote:
>>> But I had the impression the idea was discarded anyway. So I should
>>> focus my thoughts somewhere else :-)
>> Please focus your thoughts wherever you wish. I gotta ask tho; what idea?
>> I thought we were just talking about excess dependencies in the tree.
> 
> I somehow lost track of the messages in this thread
Yeah, have to admit I'd been feeling like that too- had to go back and check
what we were actually talking about :P

> , but the idea of 
> having large scale dependencies any system package needed seemed not
> realistically doable.
I thought it was to get rid of any dependencies on pkgs that were guaranteed
to be present, but I could be wrong.

> If it's just about adding virtual/c-toolchain, was there arguments
> against it?
Just the implementation difficulties, I thought. Which brought us onto a QA
db.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on system packages

[Alec Warner]

Jason Stubbs wrote:
> 
> 
> There's ways to manage this complexity, such as putting the dependencies into 
> autotools' RDEPEND (if it can be considered correct) or by using 
> meta-packages. However, your point is against requiring that packages _must_ 
> specify all system dependencies. While I personally believe that packages 
> should specify all dependencies, what I'm arguing against is requiring that 
> packages _must not_ specify any system dependencies.
> 
> --
> Jason Stubbs

I agree with your personal belief, however I also find it unmaintainable 
in the current system (metapackages in their current form 
non-withstanding as I don't think they are a great solution, merely duct 
tape if you will, but that is another discussion entirely).

There is no benefit for me as a package maintainer to dep on a system 
package unless there is an existing problem.  From a maintainer POV it's 
extra work and extra writing to keep the deps up to date.  Also there is 
the whole thought of what to list?  Do I list only glibc versions that I 
know work? gcc versions that I know compile my code?  Where does the 
line get drawn?  What is the point of depending on certain elements if 
say, they are already a dependency of $PACKAGE_MANAGER?  It is not 
pragmatic for a distribution to do so IMHO, 'technically correct' or not.

A few use cases that would go against this involve people doing odd 
things like emerging a bunch of stuff and then unmerging a critical 
system package (say, ncurses); since my program happened to depend on 
ncurses anyway it would 'fix' the problem automatically for the user 
instead of dying with no ncurses.  Of course this use case could be 
handled another way; by having portage make sure that packages listed in 
  'system' are installed.  While I am a fan of the 'fix it automatically 
in DEPEND' way here; the use case is rather...convenient.  Unmerging 
many things in system either break portage, or won't affect anything (oh 
no I unmerged virtual/editor!)

So yeah, in conclusion; too much work, fix it when it's reported broken 
seems like a decent (pragmatic) policy to me.  If/When it becomes easy 
to list stuff (package sets or something, please not metapackages in 
their current form) then I'd be much more interested in implementing it.

As an aside, If you are unsure in a given situation feel free to ask 
someone about it.  Worse case you (put an extra dep in|leave out a dep); 
both are easily repairable.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on system packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Sun, 17 Dec 2006 03:14:57 -0500 Alec Warner <antarus@gentoo.org>
wrote:
| As an aside, If you are unsure in a given situation feel free to ask 
| someone about it.  Worse case you (put an extra dep in|leave out a
| dep); both are easily repairable.

No, worst case you go and break anyone trying to do a clean install,
and then a reviewer for a large magazine happens to try to do a new
install that day and gives up because of the error.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Dependencies on system packages

[Steve Long]

Alec Warner wrote:

> Jason Stubbs wrote:
>> 
>> 
>> There's ways to manage this complexity, such as putting the dependencies
>> into autotools' RDEPEND (if it can be considered correct) or by using
>> meta-packages. However, your point is against requiring that packages
>> _must_ specify all system dependencies. While I personally believe that
>> packages should specify all dependencies, what I'm arguing against is
>> requiring that packages _must not_ specify any system dependencies.
>> 
>> --
>> Jason Stubbs
> 
> I agree with your personal belief, however I also find it unmaintainable
> in the current system (metapackages in their current form
> non-withstanding as I don't think they are a great solution, merely duct
> tape if you will, but that is another discussion entirely).
> 
> There is no benefit for me as a package maintainer to dep on a system
> package unless there is an existing problem.  From a maintainer POV it's
> extra work and extra writing to keep the deps up to date.  Also there is
> the whole thought of what to list?  Do I list only glibc versions that I
> know work? gcc versions that I know compile my code?  Where does the
> line get drawn?  What is the point of depending on certain elements if
> say, they are already a dependency of $PACKAGE_MANAGER?  It is not
> pragmatic for a distribution to do so IMHO, 'technically correct' or not.
> 
I agree but I don't think Jason was saying that; just that he should
be /allowed/ to specify a dep; clearly it should be exceptional, and maybe
tracked as an issue with the pkg.

As you mention the worse is that an extra dep goes in. But if we take the
time to hammer out the policy now (so far I'm reading don't put in a system
dep unless you really have to, and even then it may indicate an upstream
problem) it'll at least be clear.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Dependencies on system packages

[Lars Strojny]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

Hi,

Am Sonntag, den 10.12.2006, 03:22 +0100 schrieb Piotr Jaroszyński:
[...]
> It's seems to be needed sometimes b/c it does change the order of generated 
> deplist(emerge -e world). AFAIK some packages dep on zlib b/c of that.

Same thing applies for app-portage/portage-mod_jabber.

Greetings, Lars
-- 
      "Kriterium des Wahren ist nicht seine unmittelbare
          Kommunizierbarkeit an jedermann"
         -- Theodor Wiesengrund Adorno, aus: »Negative Dialektik«

name: Lars H. Strojny      web: http://strojny.net 
street: Engelsstraße 23    blog: http://usrportage.de
city: D-51103 Köln         mail/jabber: lars@strojny.net
f-print: 1FD5 D8EE D996 8E3E 1417  328A 240F 17EB 0263 AC07

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[gentoo-dev] Re: Dependencies on sys-apps/portage

[Christian Faulhammer]

Tach Stephen,                                  0x2B859DE3 (PGP-PK-ID)

Stephen Bennett schrieb:
> On which note, the current base profile specifies portage-2.0.51.22 or
> later -- can anyone see a reason not to require 2.1? There are a lot of
> packages that dep on portage-2.1 for the "wrong" reasons above, which
> I'd like to be able to clean up.

 I maintain the three ELOG viewers app-portage/ 
{elogviewer,kelogviewer,elgov} which need the ELOG feature found in  
Portage 2.1.  So I think a dependency on that version is ok, as long as it  
isn't in base-profile.


V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Dependencies on sys-apps/portage

[Stephen Bennett]

On Sun, 10 Dec 2006 09:39:41 +0100 (MET)
opfer@gentoo.org (Christian Faulhammer) wrote:

>  I maintain the three ELOG viewers app-portage/ 
> {elogviewer,kelogviewer,elgov} which need the ELOG feature found in  
> Portage 2.1.  So I think a dependency on that version is ok, as long
> as it isn't in base-profile.

Yeah. Read what I said. The dep is (semi-)valid at the moment, but I'd
like to change the base profile so that it isn't needed and can be
removed.
-- 
gentoo-dev@gentoo.org mailing list