* [gentoo-dev] need for autotools (was: Commented packages in the @system set)
2016-10-25 15:05 ` Nick Vinson
@ 2016-10-25 15:34 ` Ian Stakenvicius
2016-10-25 15:35 ` [gentoo-dev] need for autotools Ian Stakenvicius
2016-10-25 15:47 ` [gentoo-dev] Commented packages in the @system set Mike Gilbert
` (3 subsequent siblings)
4 siblings, 1 reply; 26+ messages in thread
From: Ian Stakenvicius @ 2016-10-25 15:34 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [gentoo-dev] need for autotools
2016-10-25 15:34 ` [gentoo-dev] need for autotools (was: Commented packages in the @system set) Ian Stakenvicius
@ 2016-10-25 15:35 ` Ian Stakenvicius
2016-10-25 15:41 ` Kristian Fiskerstrand
0 siblings, 1 reply; 26+ messages in thread
From: Ian Stakenvicius @ 2016-10-25 15:35 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-25 15:05 ` Nick Vinson
2016-10-25 15:34 ` [gentoo-dev] need for autotools (was: Commented packages in the @system set) Ian Stakenvicius
@ 2016-10-25 15:47 ` Mike Gilbert
2016-10-25 16:49 ` Michał Górny
2016-10-26 10:22 ` Raymond Jennings
2016-10-25 16:27 ` Rich Freeman
` (2 subsequent siblings)
4 siblings, 2 replies; 26+ messages in thread
From: Mike Gilbert @ 2016-10-25 15:47 UTC (permalink / raw
To: Gentoo Dev
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [gentoo-dev] Commented packages in the @system set
2016-10-25 15:47 ` [gentoo-dev] Commented packages in the @system set Mike Gilbert
@ 2016-10-25 16:49 ` Michał Górny
2016-10-26 10:22 ` Raymond Jennings
1 sibling, 0 replies; 26+ messages in thread
From: Michał Górny @ 2016-10-25 16:49 UTC (permalink / raw
To: Mike Gilbert; +Cc: Gentoo Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-25 15:47 ` [gentoo-dev] Commented packages in the @system set Mike Gilbert
2016-10-25 16:49 ` Michał Górny
@ 2016-10-26 10:22 ` Raymond Jennings
2016-10-26 18:55 ` Peter Stuge
1 sibling, 1 reply; 26+ messages in thread
From: Raymond Jennings @ 2016-10-26 10:22 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-25 15:05 ` Nick Vinson
2016-10-25 15:34 ` [gentoo-dev] need for autotools (was: Commented packages in the @system set) Ian Stakenvicius
2016-10-25 15:47 ` [gentoo-dev] Commented packages in the @system set Mike Gilbert
@ 2016-10-25 16:27 ` Rich Freeman
2016-10-26 0:40 ` Benda Xu
2016-10-27 0:19 ` waltdnes
4 siblings, 0 replies; 26+ messages in thread
From: Rich Freeman @ 2016-10-25 16:27 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-25 15:05 ` Nick Vinson
` (2 preceding siblings ...)
2016-10-25 16:27 ` Rich Freeman
@ 2016-10-26 0:40 ` Benda Xu
2016-10-27 0:19 ` waltdnes
4 siblings, 0 replies; 26+ messages in thread
From: Benda Xu @ 2016-10-26 0:40 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [gentoo-dev] Commented packages in the @system set
2016-10-25 15:05 ` Nick Vinson
` (3 preceding siblings ...)
2016-10-26 0:40 ` Benda Xu
@ 2016-10-27 0:19 ` waltdnes
2016-10-27 1:10 ` Peter Stuge
4 siblings, 1 reply; 26+ messages in thread
From: waltdnes @ 2016-10-27 0:19 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 0:19 ` waltdnes
@ 2016-10-27 1:10 ` Peter Stuge
2016-10-27 2:54 ` Walter Dnes
0 siblings, 1 reply; 26+ messages in thread
From: Peter Stuge @ 2016-10-27 1:10 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 1:10 ` Peter Stuge
@ 2016-10-27 2:54 ` Walter Dnes
2016-10-27 3:14 ` Rich Freeman
0 siblings, 1 reply; 26+ messages in thread
From: Walter Dnes @ 2016-10-27 2:54 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 2:54 ` Walter Dnes
@ 2016-10-27 3:14 ` Rich Freeman
2016-10-27 11:46 ` Michael Orlitzky
2016-10-27 13:07 ` Michael Mol
0 siblings, 2 replies; 26+ messages in thread
From: Rich Freeman @ 2016-10-27 3:14 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 3:14 ` Rich Freeman
@ 2016-10-27 11:46 ` Michael Orlitzky
2016-10-27 13:07 ` Michael Mol
1 sibling, 0 replies; 26+ messages in thread
From: Michael Orlitzky @ 2016-10-27 11:46 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 3:14 ` Rich Freeman
2016-10-27 11:46 ` Michael Orlitzky
@ 2016-10-27 13:07 ` Michael Mol
2016-10-27 13:21 ` Rich Freeman
1 sibling, 1 reply; 26+ messages in thread
From: Michael Mol @ 2016-10-27 13:07 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 13:07 ` Michael Mol
@ 2016-10-27 13:21 ` Rich Freeman
2016-10-27 14:41 ` Michael Mol
2016-10-28 1:27 ` Kent Fredric
0 siblings, 2 replies; 26+ messages in thread
From: Rich Freeman @ 2016-10-27 13:21 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 13:21 ` Rich Freeman
@ 2016-10-27 14:41 ` Michael Mol
2016-10-27 15:22 ` Rich Freeman
2016-10-28 1:27 ` Kent Fredric
1 sibling, 1 reply; 26+ messages in thread
From: Michael Mol @ 2016-10-27 14:41 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 14:41 ` Michael Mol
@ 2016-10-27 15:22 ` Rich Freeman
0 siblings, 0 replies; 26+ messages in thread
From: Rich Freeman @ 2016-10-27 15:22 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-27 13:21 ` Rich Freeman
2016-10-27 14:41 ` Michael Mol
@ 2016-10-28 1:27 ` Kent Fredric
2016-10-28 1:49 ` Rich Freeman
1 sibling, 1 reply; 26+ messages in thread
From: Kent Fredric @ 2016-10-28 1:27 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [gentoo-dev] Commented packages in the @system set
2016-10-28 1:27 ` Kent Fredric
@ 2016-10-28 1:49 ` Rich Freeman
0 siblings, 0 replies; 26+ messages in thread
From: Rich Freeman @ 2016-10-28 1:49 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 26+ messages in thread