[gentoo-dev] sys-libs/ncurses: punted from system in profiles

[gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Mike Frysinger]

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

ncurses is no longer part of the system deps.  in practice, this probably 
won't make a difference to most people since bash itself depends on ncurses, 
but it does make embedded/etc... simpler.
-mike

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

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Rich Freeman]

On Tue, Dec 6, 2011 at 11:17 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> ncurses is no longer part of the system deps.  in practice, this probably
> won't make a difference to most people since bash itself depends on ncurses,
> but it does make embedded/etc... simpler.

Hmm, I wonder how much further we'll have to go before you could use
portage to build an initramfs.  :)

Rich

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Alec Warner]

On Tue, Dec 6, 2011 at 8:39 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Tue, Dec 6, 2011 at 11:17 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> ncurses is no longer part of the system deps.  in practice, this probably
>> won't make a difference to most people since bash itself depends on ncurses,
>> but it does make embedded/etc... simpler.
>
> Hmm, I wonder how much further we'll have to go before you could use
> portage to build an initramfs.  :)

Whatever man, look at all this bloat!

virtual/ssh
sys-apps/kbd
sys-apps/texinfo

Ok thats about all I could find ;p

-A

>
> Rich
>

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Rich Freeman]

On Tue, Dec 6, 2011 at 11:50 AM, Alec Warner <antarus@gentoo.org> wrote:
> Whatever man, look at all this bloat!
>
> virtual/ssh

Great - I can remote access a system that doesn't boot.

> sys-apps/kbd

Full editing of config files works with my original IBM PC keyboard
(Estonian version)!

> sys-apps/texinfo

I can use a really arcane system for browsing documentation when my
system doesn't boot (perhaps from not meeting the 6GB of RAM
requirement).

Now all we need is xorg and chromium.  If we just use the native
Google version it probably doesn't even need any dependencies.  :)

Rich

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Alec Warner]

On Tue, Dec 6, 2011 at 9:00 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Tue, Dec 6, 2011 at 11:50 AM, Alec Warner <antarus@gentoo.org> wrote:
>> Whatever man, look at all this bloat!
>>
>> virtual/ssh
>
> Great - I can remote access a system that doesn't boot.
>
>> sys-apps/kbd
>
> Full editing of config files works with my original IBM PC keyboard
> (Estonian version)!
>
>> sys-apps/texinfo
>
> I can use a really arcane system for browsing documentation when my
> system doesn't boot (perhaps from not meeting the 6GB of RAM
> requirement).

To be fair, I did actually learn something from reading info pages once.

date -d @UNIXTIMESTAMP

Best feature ever.

>
> Now all we need is xorg and chromium.  If we just use the native
> Google version it probably doesn't even need any dependencies.  :)
>
> Rich
>

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1941 bytes --]

On Tuesday 06 December 2011 11:50:52 Alec Warner wrote:
> On Tue, Dec 6, 2011 at 8:39 AM, Rich Freeman wrote:
> > On Tue, Dec 6, 2011 at 11:17 AM, Mike Frysinger wrote:
> >> ncurses is no longer part of the system deps.  in practice, this
> >> probably won't make a difference to most people since bash itself
> >> depends on ncurses, but it does make embedded/etc... simpler.
> > 
> > Hmm, I wonder how much further we'll have to go before you could use
> > portage to build an initramfs.  :)
> 
> Whatever man, look at all this bloat!
> 
> virtual/ssh

i think ssh is so prevalent in today's world that it should be a default on 
all Gentoo systems.  the people who are building standalone systems to the 
point where they don't want ssh in/out are enough of a minority (in my 
educated guess) that they can go through the hassle of:
	mkdir -p /etc/portage/profile/
	echo net-misc/openssh-0 >> /etc/portage/profile/package.provided

what might be interesting is if we had a "Gentoo default" set which is what 
would come in a stage3 rather than the current "stage3 is the system set".  
then we could move virtual/ssh out of the system set and into the "Gentoo 
default" set so it'd be easier for people to drop/etc...  but i'm not familiar 
enough with the portage support atm to say how feasible such an idea would be.

> sys-apps/kbd

this controls keyboard mappings and fonts on the console.  while the default 
is probably OK for the USians, most everyone else wants to tweak these.

> sys-apps/texinfo

i personally detest info pages, but we end up needing texinfo by many many 
packages just to *build* the info pages.  and there are some info pages which 
are vastly superior to the man pages (if any are provided) because the GNU 
project has the policy of "info pages are the one true documentation format".  
compare & contrast `man gdb` to `info gdb` or `man make` vs `info make`.
-mike

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

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Rich Freeman]

On Tue, Dec 6, 2011 at 1:04 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> what might be interesting is if we had a "Gentoo default" set which is what
> would come in a stage3 rather than the current "stage3 is the system set".
> then we could move virtual/ssh out of the system set and into the "Gentoo
> default" set so it'd be easier for people to drop/etc...  but i'm not familiar
> enough with the portage support atm to say how feasible such an idea would be.
>

++

I see system about resolving the circular dependency issue - not as
installing useful apps.  After all, the system set doesn't even
include a kernel!

>> sys-apps/kbd
>
> this controls keyboard mappings and fonts on the console.  while the default
> is probably OK for the USians, most everyone else wants to tweak these.
>

I tend to agree that this is closer to a system dependency.  Even my
initramfs example might have a need for interactive input, and that
means a working keyboard layout.  As a US user I can be spoiled by the
defaults, but I appreciate the value of this.

>> sys-apps/texinfo
>
> i personally detest info pages, but we end up needing texinfo by many many
> packages just to *build* the info pages.

Still probably something better placed in DEPEND.  However, as I've
said before purging the system set is an aspirational goal and we
don't need to have a big debate over this right now.

Rich

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Zac Medico]

On 12/06/2011 10:04 AM, Mike Frysinger wrote:
> what might be interesting is if we had a "Gentoo default" set which is what 
> would come in a stage3 rather than the current "stage3 is the system set".  
> then we could move virtual/ssh out of the system set and into the "Gentoo 
> default" set so it'd be easier for people to drop/etc...  but i'm not familiar 
> enough with the portage support atm to say how feasible such an idea would be.

Similar to how we use packages.build to define the stage1 set, we could
add a packages.default to define the stage3 set. Alternatively, we could
use a meta-package to pull in the defaults, and adjust the stage3 build
to pull in that meta-package automatically.
-- 
Thanks,
Zac

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1053 bytes --]

On Tuesday 06 December 2011 14:28:02 Zac Medico wrote:
> On 12/06/2011 10:04 AM, Mike Frysinger wrote:
> > what might be interesting is if we had a "Gentoo default" set which is
> > what would come in a stage3 rather than the current "stage3 is the
> > system set". then we could move virtual/ssh out of the system set and
> > into the "Gentoo default" set so it'd be easier for people to
> > drop/etc...  but i'm not familiar enough with the portage support atm to
> > say how feasible such an idea would be.
> 
> Similar to how we use packages.build to define the stage1 set, we could
> add a packages.default to define the stage3 set. Alternatively, we could
> use a meta-package to pull in the defaults, and adjust the stage3 build
> to pull in that meta-package automatically.

the packages.default sounds like a good idea as then we'd be able to 
tweak/stack it on a per-profile basis like existing files.  i'll file a release 
bug on the topic, and then we can talk about moving virtual/ssh out of system 
and into that.
-mike

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

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Brian Harring]

On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote:
> On Tuesday 06 December 2011 14:28:02 Zac Medico wrote:
> > On 12/06/2011 10:04 AM, Mike Frysinger wrote:
> > > what might be interesting is if we had a "Gentoo default" set which is
> > > what would come in a stage3 rather than the current "stage3 is the
> > > system set". then we could move virtual/ssh out of the system set and
> > > into the "Gentoo default" set so it'd be easier for people to
> > > drop/etc...  but i'm not familiar enough with the portage support atm to
> > > say how feasible such an idea would be.
> > 
> > Similar to how we use packages.build to define the stage1 set, we could
> > add a packages.default to define the stage3 set. Alternatively, we could
> > use a meta-package to pull in the defaults, and adjust the stage3 build
> > to pull in that meta-package automatically.
> 
> the packages.default sounds like a good idea as then we'd be able to 
> tweak/stack it on a per-profile basis like existing files.  i'll file a release 
> bug on the topic, and then we can talk about moving virtual/ssh out of system 
> and into that.

We really need something generic here rather than just introducing new 
files; this basically duplicates sets for example.
~harring

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1460 bytes --]

On Tuesday 06 December 2011 16:52:55 Brian Harring wrote:
> On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote:
> > On Tuesday 06 December 2011 14:28:02 Zac Medico wrote:
> > > On 12/06/2011 10:04 AM, Mike Frysinger wrote:
> > > > what might be interesting is if we had a "Gentoo default" set which
> > > > is what would come in a stage3 rather than the current "stage3 is
> > > > the system set". then we could move virtual/ssh out of the system
> > > > set and into the "Gentoo default" set so it'd be easier for people
> > > > to drop/etc...  but i'm not familiar enough with the portage support
> > > > atm to say how feasible such an idea would be.
> > > 
> > > Similar to how we use packages.build to define the stage1 set, we could
> > > add a packages.default to define the stage3 set. Alternatively, we
> > > could use a meta-package to pull in the defaults, and adjust the
> > > stage3 build to pull in that meta-package automatically.
> > 
> > the packages.default sounds like a good idea as then we'd be able to
> > tweak/stack it on a per-profile basis like existing files.  i'll file a
> > release bug on the topic, and then we can talk about moving virtual/ssh
> > out of system and into that.
> 
> We really need something generic here rather than just introducing new
> files; this basically duplicates sets for example.

sets isn't in stable portage yet, right ?  and is it stackable in profiles ?
-mike

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

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Brian Harring]

On Tue, Dec 06, 2011 at 05:06:33PM -0500, Mike Frysinger wrote:
> On Tuesday 06 December 2011 16:52:55 Brian Harring wrote:
> > On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote:
> > > On Tuesday 06 December 2011 14:28:02 Zac Medico wrote:
> > > > On 12/06/2011 10:04 AM, Mike Frysinger wrote:
> > > > > what might be interesting is if we had a "Gentoo default" set which
> > > > > is what would come in a stage3 rather than the current "stage3 is
> > > > > the system set". then we could move virtual/ssh out of the system
> > > > > set and into the "Gentoo default" set so it'd be easier for people
> > > > > to drop/etc...  but i'm not familiar enough with the portage support
> > > > > atm to say how feasible such an idea would be.
> > > > 
> > > > Similar to how we use packages.build to define the stage1 set, we could
> > > > add a packages.default to define the stage3 set. Alternatively, we
> > > > could use a meta-package to pull in the defaults, and adjust the
> > > > stage3 build to pull in that meta-package automatically.
> > > 
> > > the packages.default sounds like a good idea as then we'd be able to
> > > tweak/stack it on a per-profile basis like existing files.  i'll file a
> > > release bug on the topic, and then we can talk about moving virtual/ssh
> > > out of system and into that.
> > 
> > We really need something generic here rather than just introducing new
> > files; this basically duplicates sets for example.
> 
> sets isn't in stable portage yet, right ?  and is it stackable in profiles ?

Bluntly, portage set support from the tree isn't something I'm sure we 
really want to support /anyways/; it's fairly portage specific last I 
looked.  Also, it isn't stackable from profiles.

Simple example of why sets.conf cannot be relied on:

# xorg sets
[x11-module-rebuild]
class = portage.sets.dbapi.VariableSet
world-candidate = false
variable = CATEGORY
includes = x11-drivers

Or using a literal overlay example:
[jmbsvicetto sets]
class = portage.sets.files.StaticFileSet
multiset = true
directory = ${repository:jmbsvicetto}/sets/

So for any non portage PM, we'd have to translate portage class name 
paths, know the actual signature of the target (VariableSet for 
example), and perfectly emulate that- also emualate the 
${var:default} interpolation.

So... there's no way in hell sets.conf can, nor should be, relied on 
if we're even pretending to try and support multiple managers.  That's 
putting it nicely. :)

package.[set-name] from profiles is a potential, although that doesn't 
work perfectly for overlays (which typically get their profile from 
the master, thus precluding the overlay from injecting a node into the 
set); could come up with something though.

~harring

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Michał Górny]

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

On Tue, 6 Dec 2011 14:27:48 -0800
Brian Harring <ferringb@gmail.com> wrote:

> On Tue, Dec 06, 2011 at 05:06:33PM -0500, Mike Frysinger wrote:
> > On Tuesday 06 December 2011 16:52:55 Brian Harring wrote:
> > > On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote:
> > > > On Tuesday 06 December 2011 14:28:02 Zac Medico wrote:
> > > > > On 12/06/2011 10:04 AM, Mike Frysinger wrote:
> > > > > > what might be interesting is if we had a "Gentoo default"
> > > > > > set which is what would come in a stage3 rather than the
> > > > > > current "stage3 is the system set". then we could move
> > > > > > virtual/ssh out of the system set and into the "Gentoo
> > > > > > default" set so it'd be easier for people to drop/etc...
> > > > > > but i'm not familiar enough with the portage support atm to
> > > > > > say how feasible such an idea would be.
> > > > > 
> > > > > Similar to how we use packages.build to define the stage1
> > > > > set, we could add a packages.default to define the stage3
> > > > > set. Alternatively, we could use a meta-package to pull in
> > > > > the defaults, and adjust the stage3 build to pull in that
> > > > > meta-package automatically.
> > > > 
> > > > the packages.default sounds like a good idea as then we'd be
> > > > able to tweak/stack it on a per-profile basis like existing
> > > > files.  i'll file a release bug on the topic, and then we can
> > > > talk about moving virtual/ssh out of system and into that.
> > > 
> > > We really need something generic here rather than just
> > > introducing new files; this basically duplicates sets for example.
> > 
> > sets isn't in stable portage yet, right ?  and is it stackable in
> > profiles ?
> 
> Bluntly, portage set support from the tree isn't something I'm sure
> we really want to support /anyways/; it's fairly portage specific
> last I looked.  Also, it isn't stackable from profiles.
> 
> Simple example of why sets.conf cannot be relied on:
> 
> # xorg sets
> [x11-module-rebuild]
> class = portage.sets.dbapi.VariableSet
> world-candidate = false
> variable = CATEGORY
> includes = x11-drivers
> 
> Or using a literal overlay example:
> [jmbsvicetto sets]
> class = portage.sets.files.StaticFileSet
> multiset = true
> directory = ${repository:jmbsvicetto}/sets/
> 
> So for any non portage PM, we'd have to translate portage class name 
> paths, know the actual signature of the target (VariableSet for 
> example), and perfectly emulate that- also emualate the 
> ${var:default} interpolation.

We wanted to replace that class with some global/generic vars, noone
was interested in cooperating. Especially the-one-whose-name-shall-
-not-be-spoken-aloud-or-he-will-come-with-his-metaphores.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Ciaran McCreesh]

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

On Tue, 6 Dec 2011 23:34:28 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> We wanted to replace that class with some global/generic vars, noone
> was interested in cooperating. Especially the-one-whose-name-shall-
> -not-be-spoken-aloud-or-he-will-come-with-his-metaphores.

As I recall, the pretty much universal response to sets in the tree is
"someone should come up with a decent format and a spec for that". I'm
not aware of anyone being opposed to the idea in general.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1991 bytes --]

On Tuesday 06 December 2011 17:27:48 Brian Harring wrote:
> On Tue, Dec 06, 2011 at 05:06:33PM -0500, Mike Frysinger wrote:
> > On Tuesday 06 December 2011 16:52:55 Brian Harring wrote:
> > > On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote:
> > > > On Tuesday 06 December 2011 14:28:02 Zac Medico wrote:
> > > > > On 12/06/2011 10:04 AM, Mike Frysinger wrote:
> > > > > > what might be interesting is if we had a "Gentoo default" set
> > > > > > which is what would come in a stage3 rather than the current
> > > > > > "stage3 is the system set". then we could move virtual/ssh out
> > > > > > of the system set and into the "Gentoo default" set so it'd be
> > > > > > easier for people to drop/etc...  but i'm not familiar enough
> > > > > > with the portage support atm to say how feasible such an idea
> > > > > > would be.
> > > > > 
> > > > > Similar to how we use packages.build to define the stage1 set, we
> > > > > could add a packages.default to define the stage3 set.
> > > > > Alternatively, we could use a meta-package to pull in the
> > > > > defaults, and adjust the stage3 build to pull in that meta-package
> > > > > automatically.
> > > > 
> > > > the packages.default sounds like a good idea as then we'd be able to
> > > > tweak/stack it on a per-profile basis like existing files.  i'll file
> > > > a release bug on the topic, and then we can talk about moving
> > > > virtual/ssh out of system and into that.
> > > 
> > > We really need something generic here rather than just introducing new
> > > files; this basically duplicates sets for example.
> > 
> > sets isn't in stable portage yet, right ?  and is it stackable in
> > profiles ?
> 
> Bluntly, portage set support from the tree isn't something I'm sure we
> really want to support /anyways/; it's fairly portage specific last I
> looked.  Also, it isn't stackable from profiles.

sounds like you support Zac's previous idea then: packages.default :)
-mike

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

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Brian Harring]

On Tue, Dec 06, 2011 at 11:34:28PM +0100, Micha?? G??rny wrote:
> On Tue, 6 Dec 2011 14:27:48 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > Simple example of why sets.conf cannot be relied on:
> > 
> > # xorg sets
> > [x11-module-rebuild]
> > class = portage.sets.dbapi.VariableSet
> > world-candidate = false
> > variable = CATEGORY
> > includes = x11-drivers
> > 
> > Or using a literal overlay example:
> > [jmbsvicetto sets]
> > class = portage.sets.files.StaticFileSet
> > multiset = true
> > directory = ${repository:jmbsvicetto}/sets/
> > 
> > So for any non portage PM, we'd have to translate portage class name 
> > paths, know the actual signature of the target (VariableSet for 
> > example), and perfectly emulate that- also emualate the 
> > ${var:default} interpolation.
> 
> We wanted to replace that class with some global/generic vars, noone
> was interested in cooperating. Especially the-one-whose-name-shall-
> -not-be-spoken-aloud-or-he-will-come-with-his-metaphores.

It's not that people aren't interested in sets, it's that the 
proposal of trying to mutate sets.conf into something people 
would be happy with is fucked from the get go.  Keep in mind pkgcore 
actually already supports the basic format (minus a few tweaks, this 
is pkgcore's raw ini format for when people need to screw w/ the 
absolute guts of it).

It is *not* a good format for compatibility; adding a couple 
global/generic class names (basic schemas) still leaves open the 
ability for people to force PM specific class settings, getting us 
right back into the original criticism I leveled- specifically leaving 
PM's having to continually play "emulate the portage api".  It's a 
shitty situation to be in, and not one alternative PM authors are 
going to willingly walk into.

sets.conf isn't viable; this was known when it was originally forced 
in.

package.[setname] for a static list of atoms is a fairly good start; 
profiles could stack it (reusing existing stack logic), and 
repositories could grow metadata/sets/[name] as a base to use for 
example.

One thing people need to agree on /prior to implementing this/, is how 
overlays will interact here.  Can they mutate an existing set?  etc.

Other thing to note, we should probably use a different name than 
package.*; set.* is saner.  If we use package.*, a naive 
implementation could interpret package.use* as a set.

~harring

Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles

[Zac Medico]

On 12/06/2011 02:52 PM, Mike Frysinger wrote:
> On Tuesday 06 December 2011 17:27:48 Brian Harring wrote:
>> On Tue, Dec 06, 2011 at 05:06:33PM -0500, Mike Frysinger wrote:
>>> On Tuesday 06 December 2011 16:52:55 Brian Harring wrote:
>>>> On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote:
>>>>> On Tuesday 06 December 2011 14:28:02 Zac Medico wrote:
>>>>>> On 12/06/2011 10:04 AM, Mike Frysinger wrote:
>>>>>>> what might be interesting is if we had a "Gentoo default" set
>>>>>>> which is what would come in a stage3 rather than the current
>>>>>>> "stage3 is the system set". then we could move virtual/ssh out
>>>>>>> of the system set and into the "Gentoo default" set so it'd be
>>>>>>> easier for people to drop/etc...  but i'm not familiar enough
>>>>>>> with the portage support atm to say how feasible such an idea
>>>>>>> would be.
>>>>>>
>>>>>> Similar to how we use packages.build to define the stage1 set, we
>>>>>> could add a packages.default to define the stage3 set.
>>>>>> Alternatively, we could use a meta-package to pull in the
>>>>>> defaults, and adjust the stage3 build to pull in that meta-package
>>>>>> automatically.
>>>>>
>>>>> the packages.default sounds like a good idea as then we'd be able to
>>>>> tweak/stack it on a per-profile basis like existing files.  i'll file
>>>>> a release bug on the topic, and then we can talk about moving
>>>>> virtual/ssh out of system and into that.
>>>>
>>>> We really need something generic here rather than just introducing new
>>>> files; this basically duplicates sets for example.
>>>
>>> sets isn't in stable portage yet, right ?  and is it stackable in
>>> profiles ?
>>
>> Bluntly, portage set support from the tree isn't something I'm sure we
>> really want to support /anyways/; it's fairly portage specific last I
>> looked.  Also, it isn't stackable from profiles.
> 
> sounds like you support Zac's previous idea then: packages.default :)

We can easily roll packages.default into the set support that's in
stable portage (no need for full-blown sets.conf support). Currently, in
stable portage, we have:

  @world = @selected + @system

How about if we add an optional @default set that's generated from
pacakges.default in the user's profile? The @default set would be pulled
in by @selected when @default is listed in /var/lib/portage/world_sets
(in stable portage, @selected currently only pulls in atoms from
/var/lib/portage/world).
-- 
Thanks,
Zac

[gentoo-dev] Re: sys-libs/ncurses: punted from system in profiles

[Duncan]

Zac Medico posted on Tue, 06 Dec 2011 15:45:26 -0800 as excerpted:

> We can easily roll packages.default into the set support that's in
> stable portage (no need for full-blown sets.conf support). Currently, in
> stable portage, we have:
> 
>   @world = @selected + @system
> 
> How about if we add an optional @default set that's generated from
> pacakges.default in the user's profile? The @default set would be pulled
> in by @selected when @default is listed in /var/lib/portage/world_sets
> (in stable portage, @selected currently only pulls in atoms from
> /var/lib/portage/world).

If @selected only pulls in /var/lib/portage/world , what pulls in
/var/lib/portage/world_sets ?  You mention it, but don't say what pulls 
it in, if as you say @selected doesn't.

-- 
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

[gentoo-dev] Re: sys-libs/ncurses: punted from system in profiles

[Duncan]

Alec Warner posted on Tue, 06 Dec 2011 08:50:52 -0800 as excerpted:

> On Tue, Dec 6, 2011 at 8:39 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Tue, Dec 6, 2011 at 11:17 AM, Mike Frysinger <vapier@gentoo.org>
>> wrote:
>>> ncurses is no longer part of the system deps.  in practice, this
>>> probably won't make a difference to most people since bash itself
>>> depends on ncurses,
>>> but it does make embedded/etc... simpler.
>>
>> Hmm, I wonder how much further we'll have to go before you could use
>> portage to build an initramfs.  :)
> 
> Whatever man, look at all this bloat!
> 
> virtual/ssh sys-apps/kbd sys-apps/texinfo
> 
> Ok thats about all I could find ;p

I've wanted ssh out of @system for years, but found I had other windmills 
to tilt at.  I do have a netbook and use ssh between my workstation and 
it, but for years I didn't, and surely, there's a lot of other gentoo 
users to whom that applies as well.

I'd argue that ssh no more belongs in the system set than does xorg-
server.  They're both at the same level of optional, or at least arguably 
should be, on a gentoo system.

Of course the same applies to kbd and texinfo.  All three should be 
packages that users can pull in if they need them, just as they pull in 
xorg-server if they need it.

But I've tilted enough at that windmill for now...

-- 
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

Re: [gentoo-dev] Re: sys-libs/ncurses: punted from system in profiles

[Zac Medico]

On 12/06/2011 09:21 PM, Duncan wrote:
> Zac Medico posted on Tue, 06 Dec 2011 15:45:26 -0800 as excerpted:
> 
>> We can easily roll packages.default into the set support that's in
>> stable portage (no need for full-blown sets.conf support). Currently, in
>> stable portage, we have:
>>
>>   @world = @selected + @system
>>
>> How about if we add an optional @default set that's generated from
>> pacakges.default in the user's profile? The @default set would be pulled
>> in by @selected when @default is listed in /var/lib/portage/world_sets
>> (in stable portage, @selected currently only pulls in atoms from
>> /var/lib/portage/world).
> 
> If @selected only pulls in /var/lib/portage/world , what pulls in
> /var/lib/portage/world_sets ?  You mention it, but don't say what pulls 
> it in, if as you say @selected doesn't.

Currently, in portage-2.2.x, @selected pulls in both
/var/lib/portage/world and /var/lib/portage/world_sets. If we want, we
can easily do it that way in stable too.
-- 
Thanks,
Zac

[gentoo-dev] Re: sys-libs/ncurses: punted from system in profiles

[Duncan]

Zac Medico posted on Tue, 06 Dec 2011 21:53:20 -0800 as excerpted:

> On 12/06/2011 09:21 PM, Duncan wrote:
>> Zac Medico posted on Tue, 06 Dec 2011 15:45:26 -0800 as excerpted:
>> 
>>> /var/lib/portage/world_sets (in stable portage, @selected currently
>>> only pulls in atoms from /var/lib/portage/world).
>> 
>> If @selected only pulls in /var/lib/portage/world , what pulls in
>> /var/lib/portage/world_sets ?  You mention it, but don't say what pulls
>> it in, if as you say @selected doesn't.
> 
> Currently, in portage-2.2.x, @selected pulls in both
> /var/lib/portage/world and /var/lib/portage/world_sets. If we want, we
> can easily do it that way in stable too.

Thanks for the clarification.

I missed your "in stable portage" clause that was right there in the bit 
I quoted, and was rather confused as a result. =:^(

-- 
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