[gentoo-dev] Commented packages in the @system set

[gentoo-dev] Commented packages in the @system set

[Michael Orlitzky]

Looking at profiles/base/packages, I see a bunch of lines that are
commented out. For example,

  *sys-apps/which
  #*sys-devel/autoconf
  #*sys-devel/automake
  *sys-devel/binutils
  #*sys-devel/bison
  #*sys-devel/flex
  *sys-devel/gcc

Does anyone know why those are commented as opposed to just.. not there?

Re: [gentoo-dev] Commented packages in the @system set

[Alexis Ballier]

On Mon, 24 Oct 2016 20:43:44 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> Looking at profiles/base/packages, I see a bunch of lines that are
> commented out. For example,
> 
>   *sys-apps/which
>   #*sys-devel/autoconf
>   #*sys-devel/automake
>   *sys-devel/binutils
>   #*sys-devel/bison
>   #*sys-devel/flex
>   *sys-devel/gcc
> 
> Does anyone know why those are commented as opposed to just.. not
> there?


Those used to be in @system and were dropped at some point once ebuilds
had proper deps. My guess would be ppl wanted to keep them commented
out just in case it appeared to be a bad idea to drop them and be able
to "revert" easily. Nowadays, we can probably assume it was ok :)


Alexis.

Re: [gentoo-dev] Commented packages in the @system set

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1048 bytes --]

On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> On Mon, 24 Oct 2016 20:43:44 -0400
> Michael Orlitzky <mjo@gentoo.org> wrote:
> 
>> Looking at profiles/base/packages, I see a bunch of lines that are
>> commented out. For example,
>>
>>   *sys-apps/which
>>   #*sys-devel/autoconf
>>   #*sys-devel/automake
>>   *sys-devel/binutils
>>   #*sys-devel/bison
>>   #*sys-devel/flex
>>   *sys-devel/gcc
>>
>> Does anyone know why those are commented as opposed to just.. not
>> there?
> 
> 
> Those used to be in @system and were dropped at some point once ebuilds
> had proper deps. My guess would be ppl wanted to keep them commented
> out just in case it appeared to be a bad idea to drop them and be able
> to "revert" easily. Nowadays, we can probably assume it was ok :)
> 

Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
or QA has any objections.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-dev] Commented packages in the @system set

[Raymond Jennings]

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

Don't you need autoconf and automake to build a lot of packages?

On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand <k_f@gentoo.org>
wrote:

> On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> > On Mon, 24 Oct 2016 20:43:44 -0400
> > Michael Orlitzky <mjo@gentoo.org> wrote:
> >
> >> Looking at profiles/base/packages, I see a bunch of lines that are
> >> commented out. For example,
> >>
> >>   *sys-apps/which
> >>   #*sys-devel/autoconf
> >>   #*sys-devel/automake
> >>   *sys-devel/binutils
> >>   #*sys-devel/bison
> >>   #*sys-devel/flex
> >>   *sys-devel/gcc
> >>
> >> Does anyone know why those are commented as opposed to just.. not
> >> there?
> >
> >
> > Those used to be in @system and were dropped at some point once ebuilds
> > had proper deps. My guess would be ppl wanted to keep them commented
> > out just in case it appeared to be a bad idea to drop them and be able
> > to "revert" easily. Nowadays, we can probably assume it was ok :)
> >
>
> Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
> or QA has any objections.
>
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

[-- Attachment #2: Type: text/html, Size: 1949 bytes --]

Re: [gentoo-dev] Commented packages in the @system set

[Alexis Ballier]

On Tue, 25 Oct 2016 07:11:48 -0700
Raymond Jennings <shentino@gmail.com> wrote:

> Don't you need autoconf and automake to build a lot of packages?

A lot. Once they're built, you dont need these anymore.

Re: [gentoo-dev] Commented packages in the @system set

[Nick Vinson]

[-- Attachment #1.1: Type: text/plain, Size: 2138 bytes --]

Theoretically no.  When autotools is used correctly, the release tarball
has no dependency on either.  That said, many people don't generate /
distribute a release tarball.

However, I don't think this is the criterion used to determine what
should be in @system.  The wiki defines the system set as the set that
"contains the software packages required for a standard Gentoo Linux
installation to run properly".

That definition definitely excludes automake and autoconf (arguably gcc
should also excluded, under that definition, so the wiki might not be
100% correct).

-Nicholas Vinson

On 10/25/2016 07:11 AM, Raymond Jennings wrote:
> Don't you need autoconf and automake to build a lot of packages?
> 
> On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand <k_f@gentoo.org
> <mailto:k_f@gentoo.org>> wrote:
> 
>     On 10/25/2016 04:01 PM, Alexis Ballier wrote:
>     > On Mon, 24 Oct 2016 20:43:44 -0400
>     > Michael Orlitzky <mjo@gentoo.org <mailto:mjo@gentoo.org>> wrote:
>     >
>     >> Looking at profiles/base/packages, I see a bunch of lines that are
>     >> commented out. For example,
>     >>
>     >>   *sys-apps/which
>     >>   #*sys-devel/autoconf
>     >>   #*sys-devel/automake
>     >>   *sys-devel/binutils
>     >>   #*sys-devel/bison
>     >>   #*sys-devel/flex
>     >>   *sys-devel/gcc
>     >>
>     >> Does anyone know why those are commented as opposed to just.. not
>     >> there?
>     >
>     >
>     > Those used to be in @system and were dropped at some point once ebuilds
>     > had proper deps. My guess would be ppl wanted to keep them commented
>     > out just in case it appeared to be a bad idea to drop them and be able
>     > to "revert" easily. Nowadays, we can probably assume it was ok :)
>     >
> 
>     Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
>     or QA has any objections.
> 
>     --
>     Kristian Fiskerstrand
>     OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
>     <http://pool.sks-keyservers.net>
>     fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> 


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

[gentoo-dev] need for autotools (was: Commented packages in the @system set)

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 998 bytes --]

On 25/10/16 11:05 AM, Nick Vinson wrote:
> On 10/25/2016 07:11 AM, Raymond Jennings wrote:
>> Don't you need autoconf and automake to build a lot of packages?
> 
> Theoretically no.  When autotools is used correctly, the release tarball
> has no dependency on either.  That said, many people don't generate /
> distribute a release tarball.
> 
> However, I don't think this is the criterion used to determine what
> should be in @system.  The wiki defines the system set as the set that
> "contains the software packages required for a standard Gentoo Linux
> installation to run properly".
> 
> That definition definitely excludes automake and autoconf (arguably gcc
> should also excluded, under that definition, so the wiki might not be
> 100% correct).
> 
> -Nicholas Vinson
> 

Unless you need to patch the build system, in which case you need to
re-run autoconf/automake/etc (usually via 'eautoreconf').  And there's
-plenty- of instances of that around as well.




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

Re: [gentoo-dev] need for autotools

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1232 bytes --]

On 25/10/16 11:34 AM, Ian Stakenvicius wrote:
> On 25/10/16 11:05 AM, Nick Vinson wrote:
>> On 10/25/2016 07:11 AM, Raymond Jennings wrote:
>>> Don't you need autoconf and automake to build a lot of packages?
>>
>> Theoretically no.  When autotools is used correctly, the release tarball
>> has no dependency on either.  That said, many people don't generate /
>> distribute a release tarball.
>>
>> However, I don't think this is the criterion used to determine what
>> should be in @system.  The wiki defines the system set as the set that
>> "contains the software packages required for a standard Gentoo Linux
>> installation to run properly".
>>
>> That definition definitely excludes automake and autoconf (arguably gcc
>> should also excluded, under that definition, so the wiki might not be
>> 100% correct).
>>
>> -Nicholas Vinson
>>
> 
> Unless you need to patch the build system, in which case you need to
> re-run autoconf/automake/etc (usually via 'eautoreconf').  And there's
> -plenty- of instances of that around as well.
> 

I forgot to mention that autotools.eclass brings in these dependencies
as-needed, though, so I agree that they definitely are not required in
the @system set.


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

Re: [gentoo-dev] need for autotools

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 515 bytes --]

On 10/25/2016 05:35 PM, Ian Stakenvicius wrote:
> I forgot to mention that autotools.eclass brings in these dependencies
> as-needed, though, so I agree that they definitely are not required in
> the @system set.

Also keep in mind, they are already not part of @system, the question is
whether to remove the commented out lines to clean up the packages file.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-dev] Commented packages in the @system set

[Mike Gilbert]

On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson <nvinson234@gmail.com> wrote:
> That definition definitely excludes automake and autoconf (arguably gcc
> should also excluded, under that definition, so the wiki might not be
> 100% correct).

gcc provides libstdc++.so.6, which is a necessary runtime component on
most systems.

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson <nvinson234@gmail.com> wrote:
>
> However, I don't think this is the criterion used to determine what
> should be in @system.  The wiki defines the system set as the set that
> "contains the software packages required for a standard Gentoo Linux
> installation to run properly".
>

IMO that is a pretty poor definition, and we aren't really forced to
stick with it regardless of how it got there.

But, I tend to be an advocate of a minimal @system.  Really, I'd
prefer if it were split and renamed @bootstrap and @common or
something like that, and if it was only used by catalyst and could not
be relied upon as being installed by default.  My all means stick it
in the default /var/lib/portage/world for convenience, but users
shouldn't get scary warnings when they uninstall openssh.


-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Michał Górny]

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

On Tue, 25 Oct 2016 11:47:05 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson <nvinson234@gmail.com> wrote:
> > That definition definitely excludes automake and autoconf (arguably gcc
> > should also excluded, under that definition, so the wiki might not be
> > 100% correct).  
> 
> gcc provides libstdc++.so.6, which is a necessary runtime component on
> most systems.

...for packages built with libstdc++ runtime. Unless you want to have
USE flags for that on every package, you just have to assume that
the user will keep the runtime for his compiler installed.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Commented packages in the @system set

[Benda Xu]

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

Nick Vinson <nvinson234@gmail.com> writes:

> arguably gcc should also excluded, under that definition, so the wiki
> might not be 100% correct

This is not true regarding libgcc* runtime libraries.

Benda

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

Re: [gentoo-dev] Commented packages in the @system set

[Raymond Jennings]

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

Why exactly isn't libstdc++ a separate package anyway?

We already have glibc as a separate package, so why the difference?

On Tue, Oct 25, 2016 at 8:47 AM, Mike Gilbert <floppym@gentoo.org> wrote:

> On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson <nvinson234@gmail.com>
> wrote:
> > That definition definitely excludes automake and autoconf (arguably gcc
> > should also excluded, under that definition, so the wiki might not be
> > 100% correct).
>
> gcc provides libstdc++.so.6, which is a necessary runtime component on
> most systems.
>
>

[-- Attachment #2: Type: text/html, Size: 966 bytes --]

Re: [gentoo-dev] Commented packages in the @system set

[Peter Stuge]

Raymond Jennings wrote:
> Why exactly isn't libstdc++ a separate package anyway?

I guess because it has no separate upstream.

I think a separate package would be a fantastic improvement though.


//Peter

Re: [gentoo-dev] Commented packages in the @system set

[waltdnes]

On Tue, Oct 25, 2016 at 08:05:55AM -0700, Nick Vinson wrote
> Theoretically no.  When autotools is used correctly, the release tarball
> has no dependency on either.  That said, many people don't generate /
> distribute a release tarball.
> 
> However, I don't think this is the criterion used to determine what
> should be in @system.  The wiki defines the system set as the set that
> "contains the software packages required for a standard Gentoo Linux
> installation to run properly".
> 
> That definition definitely excludes automake and autoconf (arguably gcc
> should also excluded, under that definition, so the wiki might not be
> 100% correct).

  A binary distro can get by without gcc.  For that matter, so could a
Gentoo "snapshot".  But my definition of "run properly" includes being
able to update software for new features and security fixes.  For a
build-from-source distro like Gentoo, gcc and associated tools are a
vital part of the distro.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Commented packages in the @system set

[Peter Stuge]

waltdnes@waltdnes.org wrote:
> For a build-from-source distro like Gentoo, gcc and associated
> tools are a vital part of the distro.

A stage4 created (and updated) on a catalyst build farm doesn't need
to have gcc, but may still need libstdc++.


//Peter

Re: [gentoo-dev] Commented packages in the @system set

[Walter Dnes]

On Thu, Oct 27, 2016 at 01:10:10AM +0000, Peter Stuge wrote
> waltdnes@waltdnes.org wrote:
> > For a build-from-source distro like Gentoo, gcc and associated
> > tools are a vital part of the distro.
> 
> A stage4 created (and updated) on a catalyst build farm doesn't need
> to have gcc, but may still need libstdc++.

  That just moves the requirement for gcc+tools to the catalyst build
farm.  OK, let's get specific... a *STANDALONE* Gentoo machine requires
gcc+tools.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Thu, Oct 27, 2016 at 01:10:10AM +0000, Peter Stuge wrote
>> waltdnes@waltdnes.org wrote:
>> > For a build-from-source distro like Gentoo, gcc and associated
>> > tools are a vital part of the distro.
>>
>> A stage4 created (and updated) on a catalyst build farm doesn't need
>> to have gcc, but may still need libstdc++.
>
>   That just moves the requirement for gcc+tools to the catalyst build
> farm.  OK, let's get specific... a *STANDALONE* Gentoo machine requires
> gcc+tools.

This is why I think "@system" oversimplifies all of this.  IMO we
should just specify all dependencies for everything (and those could
include some virtuals for convenience, like the C toolchain), and then
have different sets or virtuals for convenience.  By all means give a
user with a default install that sticks virtual/common-packages or
something in their @world.  Nobody is arguing that the typical Gentoo
user doesn't want gcc, or that we should force people to explicitly
install it.

Fixing the dependencies means that system packages can take advantage
of parallel builds, which means faster updates for everybody.  We can
still have sets for bootstraping (and I suspect that having more
virtuals or sets would allow stage1/2 definition to be simplified).

It is a bit like license groups.  We give everybody a default set of
license groups that generally makes sense.  But, if you want you can
easily edit your make.conf to exclude anything that is copyleft from
your system.

The main downside to this is it is a bit more of a hassle for
developers to maintain the dependency lists, since invariably you end
up with a lot of mundane stuff in there.  And of course it is a lot of
change to implement, though it could be done gradually.  And of course
the upside for the typcal user is somewhat limited, since most people
aren't dying to uninstall openssh or gcc.

-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Michael Orlitzky]

On 10/26/2016 11:14 PM, Rich Freeman wrote:
> 
> This is why I think "@system" oversimplifies all of this.  IMO we
> should just specify all dependencies for everything (and those could
> include some virtuals for convenience, like the C toolchain), and then
> have different sets or virtuals for convenience...
> 

And no one agrees on what can be omitted from (R)DEPEND, so all of our
ebuilds are missing different subsets of @system. Another benefit would
be that, if every dependency is specified, it becomes possible to
sandbox the build based on DEPEND. Doing so would guarantee that the
build-time dependencies at least are correct (well, sufficient).

The sooner we make "specify all dependencies" the recommendation, the
better.

Re: [gentoo-dev] Commented packages in the @system set

[Michael Mol]

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

On Wednesday, October 26, 2016 11:14:53 PM Rich Freeman wrote:
> On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> > On Thu, Oct 27, 2016 at 01:10:10AM +0000, Peter Stuge wrote
> > 
> >> waltdnes@waltdnes.org wrote:
> >> > For a build-from-source distro like Gentoo, gcc and associated
> >> > tools are a vital part of the distro.
> >> 
> >> A stage4 created (and updated) on a catalyst build farm doesn't need
> >> to have gcc, but may still need libstdc++.
> >> 
> >   That just moves the requirement for gcc+tools to the catalyst build
> > 
> > farm.  OK, let's get specific... a *STANDALONE* Gentoo machine requires
> > gcc+tools.
> 
> This is why I think "@system" oversimplifies all of this.  IMO we
> should just specify all dependencies for everything (and those could
> include some virtuals for convenience, like the C toolchain), and then
> have different sets or virtuals for convenience.  By all means give a
> user with a default install that sticks virtual/common-packages or
> something in their @world.  Nobody is arguing that the typical Gentoo
> user doesn't want gcc, or that we should force people to explicitly
> install it.
> 
> Fixing the dependencies means that system packages can take advantage
> of parallel builds, which means faster updates for everybody.  We can
> still have sets for bootstraping (and I suspect that having more
> virtuals or sets would allow stage1/2 definition to be simplified).
> 
> It is a bit like license groups.  We give everybody a default set of
> license groups that generally makes sense.  But, if you want you can
> easily edit your make.conf to exclude anything that is copyleft from
> your system.
> 
> The main downside to this is it is a bit more of a hassle for
> developers to maintain the dependency lists, since invariably you end
> up with a lot of mundane stuff in there.  And of course it is a lot of
> change to implement, though it could be done gradually.  And of course
> the upside for the typcal user is somewhat limited, since most people
> aren't dying to uninstall openssh or gcc.

I want to +1 this, but I do see one problem: If all dependencies are defined, 
how does "emerge --with-bdeps=y --emptytree @world" work? Defining all 
dependencies means the graph is completely cyclic.

Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree 
@world twice' if you want to ensure every package is rebuilt with its newest 
available build dependencies.

I'll sometimes do an "emerge -e @world" twice following a compiler upgrade or 
CFLAGS or LDFLAGS change.

-- 
:wq

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

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol <mikemol@gmail.com> wrote:
>
> I want to +1 this, but I do see one problem: If all dependencies are defined,
> how does "emerge --with-bdeps=y --emptytree @world" work? Defining all
> dependencies means the graph is completely cyclic.

Well, we'll need to define some kind of stage1 set no matter what we
do because of the bootstrapping problem.  Perhaps this can be
leveraged when breaking cyclical dependencies (optimize as much as you
can, allow parallel builds, but do the stuff in the stage1 set first
and don't treat circular deps as show-stoppers).

And I don't think portage actually breaks today with circular deps as
long as some start out satisfied.  If a depends on b and b depends on
a, and both have an upgrade, but the dependencies are unversioned,
then I think portage just does them in arbitrary order.  Now, if both
have circular versioned dependencies and you don't have at least one
installed, you're stuck (maybe a really clever portage might find
earlier intermediate versions with relaxed dependencies that break
this cycle, but I'd be surprised if that works today).

> Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree
> @world twice' if you want to ensure every package is rebuilt with its newest
> available build dependencies.

Well, if your goal is completely consistent rebuilds you can't avoid
the need to rebuild the stage1 set twice because of the bootstrapping
problem (which I believe is why we have stage2).  A solution would be
to first emerge the stage1 set, then do the emerge @world.  However,
in practice I don't think there are many situations where you really
need to do a rebuild of this scale.

I'm not saying you can completely avoid the need for having some kind
of bootstrapping stage1.  I'm just saying we should separate that need
from the issue of fully specifying dependencies, at least in an ideal
world where we're unconcerned with the effort of specifying
dependencies.


-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Michael Mol]

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

On Thursday, October 27, 2016 09:21:06 AM Rich Freeman wrote:
> On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol <mikemol@gmail.com> wrote:
> > I want to +1 this, but I do see one problem: If all dependencies are
> > defined, how does "emerge --with-bdeps=y --emptytree @world" work?
> > Defining all dependencies means the graph is completely cyclic.
> 
> Well, we'll need to define some kind of stage1 set no matter what we
> do because of the bootstrapping problem.  Perhaps this can be
> leveraged when breaking cyclical dependencies (optimize as much as you
> can, allow parallel builds, but do the stuff in the stage1 set first
> and don't treat circular deps as show-stoppers).
> 
> And I don't think portage actually breaks today with circular deps as
> long as some start out satisfied.  If a depends on b and b depends on
> a, and both have an upgrade, but the dependencies are unversioned,
> then I think portage just does them in arbitrary order.  Now, if both
> have circular versioned dependencies and you don't have at least one
> installed, you're stuck (maybe a really clever portage might find
> earlier intermediate versions with relaxed dependencies that break
> this cycle, but I'd be surprised if that works today).
> 
> > Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree
> > @world twice' if you want to ensure every package is rebuilt with its
> > newest available build dependencies.
> 
> Well, if your goal is completely consistent rebuilds you can't avoid
> the need to rebuild the stage1 set twice because of the bootstrapping
> problem (which I believe is why we have stage2).  A solution would be
> to first emerge the stage1 set, then do the emerge @world.  However,
> in practice I don't think there are many situations where you really
> need to do a rebuild of this scale.
> 
> I'm not saying you can completely avoid the need for having some kind
> of bootstrapping stage1.  I'm just saying we should separate that need
> from the issue of fully specifying dependencies, at least in an ideal
> world where we're unconcerned with the effort of specifying
> dependencies.

So, what goes in @stage1? What's the bare minimum needed for a Gentoo package 
kernel?

-- 
:wq

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

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Thu, Oct 27, 2016 at 10:41 AM, Michael Mol <mikemol@gmail.com> wrote:
>
> So, what goes in @stage1? What's the bare minimum needed for a Gentoo package
> kernel?
>

That is actually largely defined today already, but it isn't used by
anything but catalyst as far as I'm aware.  Just look at
packages.build in your profile, such as default/linux/packages.build.

Granted, even that contains a few convenience packages like
virtual/editor (I'm not sure about virtual/shadow either, though that
might be needed).  That is probably to make it easier to troubleshoot
stage1 issues.  I bet that the stage1 used by catalyst is very close
to a minimal bootstrap though.

-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Kent Fredric]

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

On Thu, 27 Oct 2016 09:21:06 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I'm not saying you can completely avoid the need for having some kind
> of bootstrapping stage1.  I'm just saying we should separate that need
> from the issue of fully specifying dependencies, at least in an ideal
> world where we're unconcerned with the effort of specifying
> dependencies.

I think you could partially solve this by having gentoo-built binaries
of things that are needed for bootstrap shipped as sys-devel/gcc-bin,
or similar.

Then for dependency cycle breaking on "there is no bootstrap GCC" would
fall back to pulling a binary GCC temporarily.

After all, that's what the stages are isn't it? Aggregates of
precompiled binaries in flying formation?


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

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:27 PM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Thu, 27 Oct 2016 09:21:06 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> I'm not saying you can completely avoid the need for having some kind
>> of bootstrapping stage1.  I'm just saying we should separate that need
>> from the issue of fully specifying dependencies, at least in an ideal
>> world where we're unconcerned with the effort of specifying
>> dependencies.
>
> I think you could partially solve this by having gentoo-built binaries
> of things that are needed for bootstrap shipped as sys-devel/gcc-bin,
> or similar.

Well, for gcc that would probably work, though I think it would make
more sense to just have a binary package of gcc and not a different
package under a different name.  I'd actually extend that to other
-bin packages we already have, like libreoffice-bin (assuming we build
that ourselves).  For the case of an upstream binary the distinction
is probably worthwhile, but for a package we build ourselves it makes
a lot more sense to just let portage build a binary package and
install it.

However, this still wouldn't eliminate the need for a stage1 set
because just to install a binary package you do need a small number of
components, like portage, bash, glibc, tar, bzip2, and so on.

I believe the way catalyst works is that it uses the host system to
build the stage1 packages and install them into the chroot.  Then from
there it can run inside the chroot to build stage2 and stage3.  All
the packages are built fresh, but the stage1 is built in the host
environment, not the target environment.

-- 
Rich