Packages that explicitly DEPEND on sys-apps/sed
 

Judging from [1], a couple of thousands of ebuilds DEPEND on
sys-apps/sed, which is a system package (in profiles/base/packages)
since at least 2004. It boils down to some 2535 ebuilds, 1409 packages
and 14 eclasses, some requiring a version as high as 4.0.5, which went
stable in 2003.

What do you say. Do we keep them or prune them from the tree?


jer



[1] http://tinderbox.dev.gentoo.org/misc/dindex/sys-apps/sed

Packages that explicitly DEPEND on sys-apps/sed
 

On Tue, 14 Jun 2011 05:58:56 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> Judging from [1], a couple of thousands of ebuilds DEPEND on
> sys-apps/sed, which is a system package (in profiles/base/packages)
> since at least 2004. It boils down to some 2535 ebuilds, 1409 packages
> and 14 eclasses, some requiring a version as high as 4.0.5, which went
> stable in 2003.

To follow up on that, some 496 ebuilds explicitly DEPEND on
sys-apps/sed, with only a few apparently needing 4.1.5 and just the one
seemingly requiring 4.2 (though it isn't obvious from the actual sed
invocation). I haven't checked which of those RDEPEND on sys-apps/sed
too, but it shouldn't be many. That means some two thousand acquire
this DEPEND from an eclass, so for the majority of packages, this
redundancy could be easily fixed, while the rest of them would probably
keep inspiring developers new and old to keep introducing the dep or
indeed be insecure about removing it.


jer

Packages that explicitly DEPEND on sys-apps/sed
 

On Tue, Jun 14, 2011 at 06:14:06AM +0200, Jeroen Roovers wrote:
> On Tue, 14 Jun 2011 05:58:56 +0200
> Jeroen Roovers <jer@gentoo.org> wrote:
>
> > Judging from [1], a couple of thousands of ebuilds DEPEND on
> > sys-apps/sed, which is a system package (in profiles/base/packages)
> > since at least 2004. It boils down to some 2535 ebuilds, 1409 packages
> > and 14 eclasses, some requiring a version as high as 4.0.5, which went
> > stable in 2003.

Since sys-apps/sed is a system package, I would vote for removing the
dependency from the ebuilds/eclasses.

William

Packages that explicitly DEPEND on sys-apps/sed
 

On 06/13/2011 08:58 PM, Jeroen Roovers wrote:
> Judging from [1], a couple of thousands of ebuilds DEPEND on
> sys-apps/sed, which is a system package (in profiles/base/packages)
> since at least 2004. It boils down to some 2535 ebuilds, 1409 packages
> and 14 eclasses, some requiring a version as high as 4.0.5, which went
> stable in 2003.
>
> What do you say. Do we keep them or prune them from the tree?

It's worth noting that stage1 and stage2 tarballs do not contain full
system sets. Therefore, we can't assume that sys-apps/sed will be
included in those stages unless we use something other than the system
set to pull it into the stage1. A couple of possible a solutions are:

A) Modify $PORTDIR/scripts/bootstrap.sh to ensure that sed is installed
in stage1.

B) Keep a sys-apps/sed dependency in the sys-apps/portage ebuilds, so
that bootstrap.sh will pull sed into stage1 as a dependency of
sys-apps/portage.

--
Thanks,
Zac

Packages that explicitly DEPEND on sys-apps/sed
 

On Mon, Jun 13, 2011 at 11:41:54PM -0500, William Hubbs wrote:
> On Tue, Jun 14, 2011 at 06:14:06AM +0200, Jeroen Roovers wrote:
> > On Tue, 14 Jun 2011 05:58:56 +0200
> > Jeroen Roovers <jer@gentoo.org> wrote:
> >
> > > Judging from [1], a couple of thousands of ebuilds DEPEND on
> > > sys-apps/sed, which is a system package (in profiles/base/packages)
> > > since at least 2004. It boils down to some 2535 ebuilds, 1409 packages
> > > and 14 eclasses, some requiring a version as high as 4.0.5, which went
> > > stable in 2003.
>
> Since sys-apps/sed is a system package, I would vote for removing the
> dependency from the ebuilds/eclasses.

The implicit system set dependency thing really, really needs to die;
at the time of the rule, portage couldn't handle resolving graphs of
that sort. PM resolvers for gentoo are generally a fair bit saner
now thus doing what you're suggesting isn't really beneficial (frankly
it causes some issues for stages, as zac noted).

~brian

Packages that explicitly DEPEND on sys-apps/sed
 

On 06/14/2011 03:54 PM, Brian Harring wrote:
> On Mon, Jun 13, 2011 at 11:41:54PM -0500, William Hubbs wrote:
>> On Tue, Jun 14, 2011 at 06:14:06AM +0200, Jeroen Roovers wrote:
>>> On Tue, 14 Jun 2011 05:58:56 +0200
>>> Jeroen Roovers <jer@gentoo.org> wrote:
>>>
>>>> Judging from [1], a couple of thousands of ebuilds DEPEND on
>>>> sys-apps/sed, which is a system package (in profiles/base/packages)
>>>> since at least 2004. It boils down to some 2535 ebuilds, 1409 packages
>>>> and 14 eclasses, some requiring a version as high as 4.0.5, which went
>>>> stable in 2003.
>>
>> Since sys-apps/sed is a system package, I would vote for removing the
>> dependency from the ebuilds/eclasses.
>
> The implicit system set dependency thing really, really needs to die;
> at the time of the rule, portage couldn't handle resolving graphs of
> that sort. PM resolvers for gentoo are generally a fair bit saner
> now thus doing what you're suggesting isn't really beneficial (frankly
> it causes some issues for stages, as zac noted).
>
> ~brian
>

I fixed that implicit system depend rule[1] in devmanual some year ago
to mention there are exceptions and leaving them out might break
building order... "Note that this rule also needs consideration for
packages like", "break building order", ...

[1] http://devmanual.gentoo.org/general-concepts/dependencies/index.html

But I'm fine with making it even more clear if that doesn't make the
case as is

- Samuli

Packages that explicitly DEPEND on sys-apps/sed
 

On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring <ferringb@gmail.com> wrote:
> The implicit system set dependency thing really, really needs to die;
> at the time of the rule, portage couldn't handle resolving graphs of
> that sort. *PM resolvers for gentoo are generally a fair bit saner
> now thus doing what you're suggesting isn't really beneficial (frankly
> it causes some issues for stages, as zac noted).

++

It seems to me that the best policy would be for every package to just
list all its dependencies, and then users are free to run the default
experience that includes everything in @system, or a more trimmed-down
experience. Plus, from time to time there is some debate about
removing some package from @system and the only way to figure out what
it breaks is a long discussion on -dev and lots of tinderbox testing,
and then lots of ebuilds being modified to add the dependency back in.
With explicit dependencies it is trivial to determine.

And no, I don't think that Gentoo should fully support reduced-@system
builds, but there is no harm in making them more of a viable option.

Rich

Packages that explicitly DEPEND on sys-apps/sed
 

On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote:
> On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring <ferringb@gmail.com> wrote:
> > The implicit system set dependency thing really, really needs to die;
> > at the time of the rule, portage couldn't handle resolving graphs of
> > that sort. ?PM resolvers for gentoo are generally a fair bit saner
> > now thus doing what you're suggesting isn't really beneficial (frankly
> > it causes some issues for stages, as zac noted).
>
> ++
>
> It seems to me that the best policy would be for every package to just
> list all its dependencies, and then users are free to run the default
> experience that includes everything in @system, or a more trimmed-down
> experience.

An annoying, but valid complaint agains this is that the deps start
getting heavy to maintain for developers, and aren't always viable to
represent. Unpackers for example, are a pain in the ass for current
EAPIs- that could be reduced in pain via addition of basic implicit
deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2).

Or devs could just be nudged into adding the appropriate DEPEND.
repoman checking for it either way wouldn't be hard.

The trickier point is gcc, but in my view, that's where we get the
most gain- if the toolchain is represented in the deps it makes
integrated cross compilation easier (keyword is integrated; crossdev
already makes it reasonably straightforward I realize).


> Plus, from time to time there is some debate about
> removing some package from @system and the only way to figure out what
> it breaks is a long discussion on -dev and lots of tinderbox testing,
> and then lots of ebuilds being modified to add the dependency back in.
> With explicit dependencies it is trivial to determine.

It also improves -e behaviour; instead of the resolver being hardcoded
to try promoting certain things (glibc and friends mainly), the
resolver's normal logic can be used there.

> And no, I don't think that Gentoo should fully support reduced-@system
> builds, but there is no harm in making them more of a viable option.

Personally... I think gentoo should aim for it actually. Question is
how close we can get to it w/out overly burdening developers.

Don't suppose someone has interest in looking into this?
~brian

Packages that explicitly DEPEND on sys-apps/sed
 

On Tuesday, June 14, 2011 19:27:47 Brian Harring wrote:
> On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote:
> > On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring <ferringb@gmail.com> wrote:
> > > The implicit system set dependency thing really, really needs to die;
> > > at the time of the rule, portage couldn't handle resolving graphs of
> > > that sort. ?PM resolvers for gentoo are generally a fair bit saner
> > > now thus doing what you're suggesting isn't really beneficial (frankly
> > > it causes some issues for stages, as zac noted).
> >
> > ++
> >
> > It seems to me that the best policy would be for every package to just
> > list all its dependencies, and then users are free to run the default
> > experience that includes everything in @system, or a more trimmed-down
> > experience.
>
> An annoying, but valid complaint agains this is that the deps start
> getting heavy to maintain for developers, and aren't always viable to
> represent. Unpackers for example, are a pain in the ass for current
> EAPIs- that could be reduced in pain via addition of basic implicit
> deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2).

i think you vastly underestimate how bad this is. what you're proposing is
the majority list:
sys-apps/baselayout (after all, it provides / /usr /usr/share /etc)
app-shells/bash
sys-apps/coreutils
sys-apps/gawk
sys-apps/grep
sys-apps/sed (every autotooled package uses it)
sys-apps/which (g'luck tracking down all the consumers)
sys-devel/gcc
sys-devel/binutils
virtual/libc
sys-apps/make

requiring people to remember to use these deps if their ebuild happens to
execute them is silly:
sys-apps/diffutils (provides `patch` after all)
sys-apps/findutils

archiving/compression deps absolutely need to be in the PM. otherwise you're
talking about:
app-arch/tar (a quick count shows 22k ebuilds need it out of all 27k)
app-arch/gzip (14k ebuilds)
app-arch/bzip2 (8k ebuilds)

these are mostly done already via the autotools eclass, so these should get
dropped from system:
sys-devel/autoconf
sys-devel/automake
sys-devel/libtool
sys-devel/m4

> The trickier point is gcc, but in my view, that's where we get the
> most gain- if the toolchain is represented in the deps it makes
> integrated cross compilation easier (keyword is integrated; crossdev
> already makes it reasonably straightforward I realize).

i dont understand this at all. sounds to me like this complicates cross-
compilation unnecessarily.
-mike

Packages that explicitly DEPEND on sys-apps/sed
 

Mike Frysinger posted on Thu, 16 Jun 2011 20:51:36 -0400 as excerpted:

>> An annoying, but valid complaint agains this is that the deps start
>> getting heavy to maintain for developers, and aren't always viable to
>> represent. Unpackers for example, are a pain in the ass for current
>> EAPIs- that could be reduced in pain via addition of basic implicit
>> deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2).
>
> i think you vastly underestimate how bad this is. what you're proposing
> is the majority list:
> sys-apps/baselayout (after all, it provides / /usr /usr/share /
etc)
> app-shells/bash sys-apps/coreutils sys-apps/gawk sys-apps/grep
> sys-apps/sed (every autotooled package uses it)
> sys-apps/which (g'luck tracking down all the consumers) sys-devel/
gcc
> sys-devel/binutils virtual/libc sys-apps/make
>
> requiring people to remember to use these deps if their ebuild happens
> to execute them is silly:
> sys-apps/diffutils (provides `patch` after all)
> sys-apps/findutils
>
> archiving/compression deps absolutely need to be in the PM. otherwise
> you're talking about:
> app-arch/tar (a quick count shows 22k ebuilds need it out of all
27k)
> app-arch/gzip (14k ebuilds)
> app-arch/bzip2 (8k ebuilds)
>
> these are mostly done already via the autotools eclass, so these should
> get dropped from system:
> sys-devel/autoconf sys-devel/automake sys-devel/libtool sys-devel/
m4

That last comment, on the autotools eclass, suggests a solution, a
basedeps eclass, which most ebuilds could simply inherit.

The eclass could handle most archiving dependencies automatically, using
source URL extensions to determine type. Similarly with stuff like make
by scanning for calls to it or emake. Bash and baselayout would be
mandatory, and variables could be used for quick-list adds and overrides.

It'd take a LOT of work and testing and may even then not be workable
unless implemented as an arbitrary list that pretty much simply moves the
@system list from its current location into an eclass, but the idea's
interesting. Possible/practical or wishful thinking?

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman