[gentoo-dev] virtual/gzip madness

[gentoo-dev] virtual/gzip madness

[Aaron Walker]

I was discussing this with kloeri and a few other devs in #gentoo-bugs 
this morning and they suggested I post this list here to get everyone's 
opinion.

It looks like seemant added virtual/gzip back in Nov 2003.  Suprisingly, 
grepping the tree reveals 1 (as in ONE) ebuild that actually uses 
virtual/gzip.

Following is a list of packages that either 1) need to have their 
apps-arch/gzip DEPEND changed to virtual/gzip, or 2) depend on gzip but 
do not have it all in any form in DEPEND.

#2 brings up a question that has confused me for a while; if an ebuild 
depends on a package (in this case gzip), which is included as part of 
the base system, is it assumed to exist or should it be added to DEPEND?

I'd be willing to fix most of these myself (provided everyone agrees, of 
course), but I'm still going through my probabtionary period.  If 
everyone agrees, and if I do end up becoming a developer, then I'd be 
more than willing to fix whatever packages haven't been fixed by that time.

So, enough hoopla...

ebuilds that currently DEPEND on app-arch/gzip but should be changed to 
virtual/gzip:

app-admin/aide
app-admin/newsyslog
app-admin/rkhunter
app-arch/guitar
app-arch/hdup
app-arch/ppmd
app-arch/tar
app-cdr/cdlabelgen
app-doc/daemontools-man
app-doc/djbdns-man
app-doc/gimp-user-manual
app-emacs/tamago
app-i18n/manpages-fr
app-i18n/manpages-it
app-i18n/skk-jisyo
app-i18n/skk-jisyo-cdb
dev-db/cdb
dev-util/quilt
mail-filter/amavisd-new
media-sound/soundtracker
net-analyzer/oinkmaster
net-firewall/fwanalog
sys-apps/miscfiles
sys-libs/cracklib
x11-themes/iceicons

ebuilds that currently use gzip explicitly but do not have any kind of 
gzip in DEPEND:

app-arch/unlzx
app-benchmarks/siege
app-doc/howto-text
app-doc/phrack
app-editors/ted
app-emulation/uade
app-i18n/ami
app-misc/emelfm
app-sci/modelsim
app-text/docbook-xsl-stylesheets
<=dev-lang/ccc-6.5.9.001-r2
dev-lang/cfal
dev-lang/cxx
dev-lang/gpc
dev-lang/squeak-basicimage
dev-lang/squeak-fullimage
dev-libs/ace
dev-libs/libcxml
dev-lisp/cmucl-source
dev-util/examiner
dev-util/ladebug
dev-util/xmingw-gcc
games-fps/lsdldoom
games-mud/tf
games-strategy/liquidwar
mail-client/mutt
media-fonts/artwiz-fonts
media-fonts/baekmuk-fonts
media-fonts/efont-unicode
media-fonts/intlfonts
media-fonts/jisx0213-fonts
media-gfx/feh
media-gfx/xzgv
media-libs/nas
media-tv/xawdecode
net-analyzer/arpwatch
net-irc/ctrlproxy
net-mail/getmail
net-news/slrn
sys-apps/kbd
sys-apps/lkcdutils
sys-apps/powerpc-utils
sys-fs/mac-fdisk
x11-base/xfree
x11-base/xorg-x11
x11-libs/qwt

Cheers
-- 
They call them "squares" because it's the most complicated shape they 
can deal with.

/*  Aaron Walker
  *  http://butsugenjitemple.org/~ka0ttic/
  */

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/gzip madness

[Aaron Walker]

Forgot to add:

I removed any packages from the list which DEPENDs on a certain version 
of app-arch/gzip.  I'm sure there will be others on the list that are 
picky as well, so that should also be taken into consideration.

Toodles
-- 
"If it ain't broke, don't fix it." - Bert Lantz

/*  Aaron Walker
  *  http://butsugenjitemple.org/~ka0ttic/
  */

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/gzip madness

[Chris Gianelloni]

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

On Mon, 2004-08-23 at 09:47, Aaron Walker wrote:
> #2 brings up a question that has confused me for a while; if an ebuild 
> depends on a package (in this case gzip), which is included as part of 
> the base system, is it assumed to exist or should it be added to DEPEND?

If the package is in system, it should not DEPEND on it *unless* it
requires a specific version or specific package (in the case of a
virtual).

-- 
Chris Gianelloni
Release Engineering - QA/Operations Manager
Games - Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] virtual/gzip madness

[Stuart Herbert]

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

On Monday 23 August 2004 15:09, Chris Gianelloni wrote:
> If the package is in system, it should not DEPEND on it *unless* it
> requires a specific version or specific package (in the case of a
> virtual).

I disagree.  Making sure that packages have as accurate a list of DEPENDs as 
possible can only make life easier when porting Gentoo to userlands that are 
not Linux.

Besides, it's good SCM behaviour.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] virtual/gzip madness

[Lina Pezzella]

Stuart Herbert wrote:

>On Monday 23 August 2004 15:09, Chris Gianelloni wrote:
>  
>
>>If the package is in system, it should not DEPEND on it *unless* it
>>requires a specific version or specific package (in the case of a
>>virtual).
>>    
>>
>
>I disagree.  Making sure that packages have as accurate a list of DEPENDs as 
>possible can only make life easier when porting Gentoo to userlands that are 
>not Linux.
>  
>
I would entirely agree on the second point there.  System for macos has 
very few things installed (gzip not among them) because a lot is 
provided by MacOS.  At this point in the game, where we are porting 
Gentoo to non-Linux userlands, it is probably a bad idea to "assume" 
much of anything.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/gzip madness

[Chris Gianelloni]

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

On Mon, 2004-08-23 at 11:36, Lina Pezzella wrote:
> I would entirely agree on the second point there.  System for macos has 
> very few things installed (gzip not among them) because a lot is 
> provided by MacOS.  At this point in the game, where we are porting 
> Gentoo to non-Linux userlands, it is probably a bad idea to "assume" 
> much of anything.

Shouldn't anything provided by MacOS itself be considered part of
"system", since it would be there and is provided by the "system"
component, which in your case happens to be MacOS?

Also, if you notice, I corrected myself.  In my original post, I did not
mean that is how it should be done, but rather how it *is* done now in
practice.

-- 
Chris Gianelloni
Release Engineering - Operations/QA Manager
Games - Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] virtual/gzip madness

[Lina Pezzella]

Chris Gianelloni wrote:

>On Mon, 2004-08-23 at 11:36, Lina Pezzella wrote:
>  
>
>>I would entirely agree on the second point there.  System for macos has 
>>very few things installed (gzip not among them) because a lot is 
>>provided by MacOS.  At this point in the game, where we are porting 
>>Gentoo to non-Linux userlands, it is probably a bad idea to "assume" 
>>much of anything.
>>    
>>
>
>Shouldn't anything provided by MacOS itself be considered part of
>"system", since it would be there and is provided by the "system"
>component, which in your case happens to be MacOS?
>
>Also, if you notice, I corrected myself.  In my original post, I did not
>mean that is how it should be done, but rather how it *is* done now in
>practice.
>
>  
>
It actually is provided by package.provided, so in the case of gzip it's 
a non-issue.  I'm sorry for not being more clear on that.  I didn't mean 
to make any statements on how it currently is done, just on how it 
should be done.  Certain non-Linux userlands may not have the same 
system requirements -- therefore imho the safest and most accurate way 
to handle the situation is to provide proper DEPENDS in ebuilds 
regardless of whether it's provided by system or not.

Just my two cents, nothing more.  :-)

Regards,
Lina Pezzella

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/gzip madness

[Paul de Vrieze]

On Monday 23 August 2004 17:36, Lina Pezzella wrote:
> I would entirely agree on the second point there.  System for macos has
> very few things installed (gzip not among them) because a lot is
> provided by MacOS.  At this point in the game, where we are porting
> Gentoo to non-Linux userlands, it is probably a bad idea to "assume"
> much of anything.

I think gzip, tar, unzip and bzip2 should be runtime dependencies of portage 
itself. Portage needs them to unpack almost all packages. It would be hell if 
we would need to add any of them as a dependency just because of the fact 
that the package is offered in a tarball of some sort (most packages are).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/gzip madness

[Will Buckner]

on 08/24/04 11:30 Paul de Vrieze said the following:
> On Monday 23 August 2004 17:36, Lina Pezzella wrote:
> 
>>I would entirely agree on the second point there.  System for macos has
>>very few things installed (gzip not among them) because a lot is
>>provided by MacOS.  At this point in the game, where we are porting
>>Gentoo to non-Linux userlands, it is probably a bad idea to "assume"
>>much of anything.
> 
> 
> I think gzip, tar, unzip and bzip2 should be runtime dependencies of portage 
> itself. Portage needs them to unpack almost all packages. It would be hell if 
> we would need to add any of them as a dependency just because of the fact 
> that the package is offered in a tarball of some sort (most packages are).
> 

This makes sense to me as well, since, in reality, it IS a portage 
dependency. It's portage that needs virtual/gzip, etc, to extract the 
package. A package's dependencies should be what the package itself needs to 
compile/run.

> Paul
> 

Wcc

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/gzip madness

[Aaron Walker]

Paul de Vrieze wrote:
> On Monday 23 August 2004 17:36, Lina Pezzella wrote:
> 
>>I would entirely agree on the second point there.  System for macos has
>>very few things installed (gzip not among them) because a lot is
>>provided by MacOS.  At this point in the game, where we are porting
>>Gentoo to non-Linux userlands, it is probably a bad idea to "assume"
>>much of anything.
> 
> 
> I think gzip, tar, unzip and bzip2 should be runtime dependencies of portage 
> itself. Portage needs them to unpack almost all packages. It would be hell if 
> we would need to add any of them as a dependency just because of the fact 
> that the package is offered in a tarball of some sort (most packages are).
> 
> Paul
> 

Was there a final verdict on this?

The two possible solutions mentioned in this thread:

1) add gzip (and others) as a portage run-time dep
2) change all DEPEND's containing app-arch/gzip to virtual/gzip

Regards
-- 
Tact, n.: The unsaid part of what you're thinking.

/*  Aaron Walker
  *  http://butsugenjitemple.org/~ka0ttic/
  */

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/gzip madness

[Chris Gianelloni]

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

On Mon, 2004-08-23 at 10:09, Chris Gianelloni wrote:
> On Mon, 2004-08-23 at 09:47, Aaron Walker wrote:
> > #2 brings up a question that has confused me for a while; if an ebuild 
> > depends on a package (in this case gzip), which is included as part of 
> > the base system, is it assumed to exist or should it be added to DEPEND?
> 
> If the package is in system, it should not DEPEND on it *unless* it
> requires a specific version or specific package (in the case of a
> virtual).

Allow me to clarify this... while this is how things are *currently*
done, it is probably not the best way to go about it, especially since
we are starting to see more divergent profiles.  After all, what if your
application actually *requires* glibc?  It definitely won't work on one
of the uclibc profiles, now will it?

-- 
Chris Gianelloni
Release Engineering - Operations/QA Manager
Games - Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]