On Thu, Oct 27, 2016 at 9:27 PM, Kent Fredric wrote:
> On Thu, 27 Oct 2016 09:21:06 -0400
> Rich Freeman 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 specifyin
On Thu, 27 Oct 2016 09:21:06 -0400
Rich Freeman 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 uncon
On Thu, Oct 27, 2016 at 10:41 AM, Michael Mol 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 p
On Thursday, October 27, 2016 09:21:06 AM Rich Freeman wrote:
> On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol 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 th
On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol 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
On Wednesday, October 26, 2016 11:14:53 PM Rich Freeman wrote:
> On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes wrote:
> > On Thu, Oct 27, 2016 at 01:10:10AM +, Peter Stuge wrote
> >
> >> waltd...@waltdnes.org wrote:
> >> > For a build-from-source distro like Gentoo, gcc and associated
> >> >
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 co
On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes wrote:
> On Thu, Oct 27, 2016 at 01:10:10AM +, Peter Stuge wrote
>> waltd...@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
On Thu, Oct 27, 2016 at 01:10:10AM +, Peter Stuge wrote
> waltd...@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 st
waltd...@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
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 de
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
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 wrote:
> On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson
> wrote:
> > That definition definitely excludes automake and autoconf
Nick Vinson 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
signature.asc
Description: PGP signature
On Tue, 25 Oct 2016 11:47:05 -0400
Mike Gilbert wrote:
> On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson 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 provid
On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson 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 properl
On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson 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 syste
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
Don't you need autoconf and automake to build a lot of packages?
On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand
wrote:
> On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> > On Mon, 24 Oct 2016 20:43:44 -0400
> > Michael Orlitzky wrote:
> >
> >> Looking at profiles/base/packages, I see a b
On Tue, 25 Oct 2016 07:11:48 -0700
Raymond Jennings 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.
On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> On Mon, 24 Oct 2016 20:43:44 -0400
> Michael Orlitzky 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
On Mon, 24 Oct 2016 20:43:44 -0400
Michael Orlitzky 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
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.
23 matches
Mail list logo
