Re: [gentoo-dev] Guidelines for IUSE defaults

[David Seifert]

On Thu, 2017-02-02 at 15:35 -0500, james wrote:
> On 02/02/2017 01:01 PM, Rich Freeman wrote:
> > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <mjo@g.o>
> > wrote:
> > >
> > > If (base == minimal), then all of the upstream defaults need to
> > > be added
> > > to package.use for the upstream-defaults profile. That's bad,
> >
> > I'll go further and say that it is unacceptably bad.
> >
> > > but if
> > > (base == upstream-defaults), then the important IUSE defaults
> > > need to be
> > > copy/pasted from our ebuilds into the minimal profile. The latter
> > > is
> > > more spiritually damning =)
> > >
> >
> > So, I'll admit I've never been one that cared a great deal about
> > minimalism so I appreciate that I may not be the best one to judge
> > this, so let's go ahead and embrace your statement for the purpose
> > of
> > debate.
> >
> > Is there a better way we can have our cake and eat it too?  I'll
> > admit
> > that a huge package.use on the minimal profile isn't a whole lot
> > better than a huge package.use on all the other profiles.
> >
> > Do we need another form of syntax in individual ebuilds to try to
> > separate out the various cases you cite?  Does anybody care to
> > actually suggest one?
>
> I think that unikernels are something everyone should be aware of
> as they purport to be the latest trend in securing all sorts of
> systems.
> (a brief read).
>
> http://unikernel.org/
>
>
> Perhaps we should not have a 'minimal profile', as it means so many 
> different things to so many different people. We have not even
> surveyed
> the user base...
>
> So if we think of all the possible profiles and sub-profiles as being
> organized in a tree structure, it is better to figure out logical 
> organization of all profiles, imho.
>
> So how about profiles that are either under the embedded or basic 
> 'moniker' in the profile tree.  So embedded is the least number of
> packages possible,  regardless of upstream, where folks build up
> from 
> there to what they want as a finished system. Embedded, clusters,
> HPC, 
> and such are compatible enough for what I'm building to be under the 
> same branch of the profile tree. If other folks want their cluster
> works 
> under the basic  part of the profile tree that is concerned with 
> upstream, then  they have their part of the profile tree located
> there.
>
> And the 'basic' part of the tree is similar to what we now call 
> 'default' and the names build up in whatever schema those target
> builds
> desire, like basic+headless, basic+kde, basic+?+whatever..... ?
>
> And is there any reason, if necessary that other needs cannot be 
> branched off, as necessary form the profile tree?  Perhaps the main
> root
> is a state diagram of what is need and has links to  relevant
> documents.
> That way the profile tree is a live system that can  be enhance or 
> modified to serve all of Gentoo's diverse visions.
>
>
> > I still think that we shouldn't encourage users to lightly deviate
> > from all the upstream defaults.  There are of course legitimate
> > reasons for doing so, and you and I can probably appreciate when we
> > should do this, but for somebody starting out we're giving them a
> > lot
> > of rope to hang themselves with.
>
> This is only the case because profiles are in general in a mess and 
> there are little in the way of conventions. What is so sacrosanct
> about 
> upstream for a truly embedded gentoo system or a gentoo based IoT 
> device? How many of the gentoo-embedded devs even bother to read
> gentoo-dev? Your vision seems to me to be tainted by the major
> distros 
> and their visions, not be impolite, but they are way off course for h
> ttp://www.easyjet.com/en/
> secure systems, embedded systems, IoT, HPC and numerous other active 
> areas of Linux, imho.
>
>
> Think about it, if upstream is so brilliant, and has our needs 'at 
> heart' then why have not the kernel-geniuses bothered to build a 
> logical, coherent semantic for kernel configurations, management, 
> security testing and such?  If fact, if I were to be critical of 
> upstream, I'd say those and many other issues should have been
> addressed 
> before the adventures of systemd were dictated upon the larger user 
> base. Upstream is an 'ad-hoc' mess, in the old days we called such 
> entities a clusterF*.
>
>
> So those of us going back to minimal and basics and such venues, even
> with clusters, could not care less about Mozilla, systemd and
> thousands
> of other upstream folks  that have lost their pathway forward.
> (deepest 
> apologies, but I have very strong feelings about "upstream*".
>
>
> Many of the profiles in this and other recent threads, are just 'ad-
> hoc' 
> naming structures and locations, and that historical flexibility
> extend 
> to the devs is fantastic. This enhance/cleaning need of gentoo
> profiles 
> needs to be well thought out and as flexible semantically as
> possible.
>
>
> It is absolutely a superior approach to not care at all what
> upstream 
> does, to provide a pathway for embedded gentoo. That is a
> fundamental 
> characteristic of what an embedded system is. Thanke the code, purge
> 90+ percent of this, and then install it on a embedded system so
> only what is needed is encluded. On a distro, you can pile on tons
> of uncessary codes, for convenience and not care, but embedded,
> it does matter. That is why so much of Iot is hacked and owned
> by folks with nefarious intentions. Much of 'upstream' is growing
> dumber by the day, and corporate manager and government interlopers
> are just loving the cruft of 'upstream'.
>
>
> Minimal is a close cousin to embedded, and now unikernels and
> aggressive 
> HPC clusters are going that direction too in the name of
> performance, 
> sane-management and reducing attack surfaces for the cloud or HPC 
> cluster (not all, but many).
>
>
> Surely a branch of the gentoo profiles tree, could rigorously be
> focused
> on compatibility with upstream, but that inflexibility, if imposed
> on everyone else, will only serve to further alienate gentoo-
> embedded 
> and serve as a unnecessary wedge between some minimal, HPC and
> unikernel
> types of gentoo builds.
>
>
>
> > It is like building a kernel
> > answering no to the largest number of questions possible while
> > still
> > actually building something.  I'd actually be curious as to what
> > that
> > kernel would even be capable of doing (there are a lot of fairly
> > essential things you can turn off in the kernel).
>
>
> This is a whole other area of valid concern. Their was a GSoC project
> last summer to work on organizing gentooish kernel builds, but that
> is a 
> very big topic. Perhaps the profiles will have to be proposed but not
> formalized until folks go out and do some kernel builds and testing 
> associated with a proposed profile organization?
>
>
> > In the same way, we shouldn't be too quick to deviate from upstream
> > defaults ourselves (#4 in your example), beyond actual integration
> > work.
> > I'll admit the current state is a bit of a compromise, but I don't
> > think we should change it unless we're changing it to something
> > significantly better.  This is a pretty big-impact change.
>
>
> Just formalize some new parts of the profile tree to not be required
> to 
> be upstream compliant. Isn't that part of being a 'meta-
> distribution'?
>
> In my future (and the future of many others) there will be
> minimalistic
> builds on clusters where any number to constructs including 
> compatibility  which will all be solved, at the framework level, not
> the 
> base distro level, to the extent possible. Folks are now running a 
> myriad of windows OS versions on linux (&clusters), so I have just
> read 
> about a few days ago. So I'm proposing and working on gentoo 
> heterogeneous cluster where one can partition part to be for systemd 
> stuffage, part to be HPC, part to be extraordinarily secure, part to
> be 
> aligned with a particularly commercial linux distro, and many other 
> differing needs based frameworks.
>
>
> The minimal (lowest level) should be clear of all of those distro 
> encumbrances. CoreOS is taking this approach, as their bare metal 
> bootstrapping occurs completely and well before systemd or any other
> PID1 schema is invoked or becomes a defacto requirement.  Gentoo is
> all 
> about freedom, right?
>
>
> hth,
> James
>

Dear James,
can you please stop totally drifting off topic and rambling about stuff
that is not relevant for the discussion at hand? We started at IUSE
defaults and you end with unikernels and HPC. Please stop the rambling.

hth,
David