Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/02/2017 04:40 PM, David Seifert wrote:
> 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
>
>
>

Hello David.

The third post integrated 'profiles' into the discussion,included here
since you must have missed that::

"
I'm not saying that we should have a minimal experience out-of-the-box,
only that the base profile should result in an effectively-minimal set
of USE flags. Adding IUSE defaults is essentially adding defaults to the
base profile. Why does dev-java/icedtea try to pull in GTK (and thus X)
on a headless server? That stuff belongs in a desktop profile, not in
the base one."
  co

Many other comments followed up and further discussed profiles. Only 
when I threw in my comments about the effects on profiles 'doth thy 
protest'?


Please give me a break, just ignore what you need to.


hth,
James