[gentoo-dev] Mix-in Support Tracker

[gentoo-dev] Mix-in Support Tracker

[Rich Freeman]

There was a thread a while back about mix-in support and I think there
was genuine interest.  For the most part we just need to do the work,
and the first step is identifying blockers.  If some end up involving
PMS/etc then we may need to get the Council involved.

Rather than hijacking every @system change discussion with this, I
created a tracker at:
https://bugs.gentoo.org/show_bug.cgi?id=523036

If somebody beats me to it, feel free to dig through the past
discussions and add blockers.  I know updating eselect is necessary.
I suspect portage will be fine if we just turn /etc/make/profile into
a directory and have it inherit other profiles.  Actually creating
some mix-in profiles will need to be done, but probably not in the
main tree until we have more of the blockers resolved.  We also need
to see how other package managers handle this, and work with them,
possibly including a PMS change.

I'd like to get to a point where we can all have our cakes and eat it
too, and not have endless arguments about whether openssh or whatever
belongs in @system.

--
Rich

Re: [gentoo-dev] Mix-in Support Tracker

[Rick "Zero_Chaos" Farina]

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

On 09/17/2014 09:58 AM, Rich Freeman wrote:
> There was a thread a while back about mix-in support and I think there
> was genuine interest.  For the most part we just need to do the work,
> and the first step is identifying blockers.  If some end up involving
> PMS/etc then we may need to get the Council involved.
> 
> Rather than hijacking every @system change discussion with this, I
> created a tracker at:
> https://bugs.gentoo.org/show_bug.cgi?id=523036

The funtoo mixin system has absolutely nothing to do with adding
packages to stage3 that are not in @system.

Primarily adding packages to stage3 (or stage4 if we choose to call it
that) would only need us to agree on the packages.default bug:
https://bugs.gentoo.org/show_bug.cgi?id=393445

The primary issue here is do we add the "default" packages to the world
file or not.

I'll provide an extremely biased reasoning for both sides:

If we add packages to the world file, then the default programs won't be
immediately eligible to depclean, and the user would have to manually
ask portage to remove them if they don't want them.  No package.provided
hacks, just normal "emerge -C blah".  The downside to this is that we
would be shipping a stage with a populated world file.  This solution
provides a very simple opt out of the packages that the user doesn't
want (just remove them) and no accidental removals.

If we don't add packages to the world file, then the default programs
will be immediately eligible to depclean, and may be accidently wiped
EVERY time depclean is run unless the user does "emerge --noreplace
blah" for every single package they want to keep.  This solution may
cause users to accidently depclean needed utilities from their systems
and have difficultly getting them back.  For instance if virtual/editor
is removed from @system and moved to packages.default (it should be)
then a depclean right after install would remove the system editor and
leave the user unable to edit files until they rebuild it (assuming they
don't need to edit any files like make.conf to do so).  As I'm not a fan
of crippling users by surprise, it should be obvious I think this idea
is bad.

Again, I'm incredibly biased, and as such, I've refused to work on this
bug because there is no agreement on the solution and I refuse to help
enable the solution where needed programs can be accidentally depcleaned
(as with nano, openssh, etc, all would be after we remove them from the
system set).  I refuse to be responsible for people accidentally
depcleaning things like openssh, I don't care that they didn't read the
--depclean -p output, that's not a valid excuse to cripple users by default.
> 
> If somebody beats me to it, feel free to dig through the past
> discussions and add blockers.  I know updating eselect is necessary.
> I suspect portage will be fine if we just turn /etc/make/profile into
> a directory and have it inherit other profiles.  Actually creating
> some mix-in profiles will need to be done, but probably not in the
> main tree until we have more of the blockers resolved.  We also need
> to see how other package managers handle this, and work with them,
> possibly including a PMS change.
> 
> I'd like to get to a point where we can all have our cakes and eat it
> too, and not have endless arguments about whether openssh or whatever
> belongs in @system.

No, we can move those arguments to if things belong in packages.default :-)

-Zero_Chaos
> 
> --
> Rich
> 
> 



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

Re: [gentoo-dev] Mix-in Support Tracker

[Rich Freeman]

On Wed, Sep 17, 2014 at 3:25 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
>
> The funtoo mixin system has absolutely nothing to do with adding
> packages to stage3 that are not in @system.
>
> Primarily adding packages to stage3 (or stage4 if we choose to call it
> that) would only need us to agree on the packages.default bug:
> https://bugs.gentoo.org/show_bug.cgi?id=393445
>
>...
> No, we can move those arguments to if things belong in packages.default :-)
>

Well, yes and no.  Mixins would allow us to have more than one
packages.default as well.

The point is that rather than arguing over one configuration and what
goes in and out, we can have 47 different configurations that aren't
hard to maintain and everybody can have their own idea of what goes in
and out.  Plus, those configurations will probably make sense since
instead of "server" we might have "postfix server" or "LAMP box" and
so on.  Nobody argues with having systemd in the Gnome3 desktop
profile (well, at least not with Gentoo's role in putting it there),
because in that context it makes sense, while putting it in the
default profile would be a highly controversial matter.  Choice is a
way to get around arguments like this.

--
Rich

[gentoo-dev] Re: Mix-in Support Tracker

[Duncan]

Rich Freeman posted on Wed, 17 Sep 2014 09:58:46 -0400 as excerpted:

> [Mix-in support] For the most part we just need to do the work, and the
> first step is identifying blockers.  If some end up involving PMS/etc
> then we may need to get the Council involved.
> 
> Rather than hijacking every @system change discussion with this, I
> created a tracker at:
> https://bugs.gentoo.org/show_bug.cgi?id=523036

Thanks.  This does seem a useful way to take gentoo to the next level. 
=:^)

While I'm no PMS authority, given that we're talking profiles here, 
definitely the other PMs will have to be involved, and I'd guess PMS as 
well.  When the time comes the mix-ins profiles will need added to the 
tree and eventually, to become the default.  Major bits of that will 
require council approval.

So a tracking bug is definitely a good first step and demonstrates taking 
ownership, but I'd also suggest a GLEP.  Certainly it's a big enough 
change to deserve one, and getting a reasonably formal proposal out there 
and hashed out will provide a guideline for the various steps as they 
proceed.

Thanks again.  The closest comparable would have to be the switch to 
cascading profiles, with this arguably step two of that project, finally 
allowing the locked up potential to blossom. =:^)

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