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

[Rick \\\"Zero_Chaos\\\" Farina]

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