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 > >
signature.asc
Description: OpenPGP digital signature
