On 01/27/2017 12:25 PM, Michael Orlitzky wrote:
Forked from the gdbm/berkdb thread, wall of text ensues...
On 01/27/2017 03:32 AM, Fabian Groffen wrote:
You mention REQUIRED_USE should be used sparingly, I think I see your
reasoning, but if so, then why did we add it in the first place?
There are a few conflicting interests at play. Before REQUIRED_USE, we
would have a bunch of checks in pkg_pretend() to test if the user's
configuration was invalid. If it was, we could output a nice explanation
and tell him to try again. But, bash code in pkg_pretend can't be
understood by the package manager, and requires execution to determine
if a package can be installed. So we got REQUIRED_USE, which fixes those
problems, and introduces a new one: no one knows WTF to do when portage
outputs a REQUIRED_USE error. Now you get what looks like a core dump of
the dependency graph instead of "this package only uses one database, so
pick either mysql or sqlite."
Both approaches have another problem: USE flag constraints on packages
simply don't work with global USE flags. Global USE flags don't work
that well to begin with, since the same flag means different things to
each package (and the fact that they're global means "enable foo" is all
we get for documentation). Regardless, when you have 100 flags enabled
globally and start installing thousands of packages with USE
constraints, you're eventually going to get to a point where everything
has conflicting requirements and you need to switch to package.use to
sort it all out.
Both pkg_pretend and REQUIRED_USE have that problem and try to solve it
in different ways. If you don't care about machine-readability, then in
pkg_pretend you could try to choose "the best" of two conflicting flags
and just silently go with it. There are a lot of problems with that,
like what happens if you need to add a conditional dependency on those
flags (you can't change DEPEND in pkg_pretend). With REQUIRED_USE, you
instead need to set IUSE defaults to get it to do something without user
interaction, but the tricks that you can do with IUSE don't solve every
REQUIRED_USE conflict. In the harder cases, you can try to figure out
what to do on behalf of the user in the ebuild, but then you're right
back to the same set of problems that you had with pkg_pretend, because
the decision is being made in code and not in metadata/flags.
I think a slow migration away from global USE flags is the only way out
of the jam. We get better USE flag docs for free, and no REQUIRED_USE
conflicts that the user didn't cause himself. We could probably also get
rid of a lot of IUSE defaults that serve only to undo various profile
defaults. It would be annoying at first, but once a few critical profile
defaults are moved into package.use, better.
Exactly:: simplify the flags, profiles and associated constructs down to
the bare bones. Even embedded (arm/mips/etc) builds could benefit from a
really minimized gentoo as a starting point. Freedom to build and fork
Gentoo, per GLEP 70 is a wonderful idea, whose time has arrived. That
would set the stage for quickly building highly specific gentoo installs
(VMs, Containers, Clusters or unikernel); all via a 'recipe' from the
minimal core-sed, which could then take a variety of forms, such as
bare-metal builds vi IPMI, ipxe, or more traditional formularies like
chef, puppet, ansible as well as a myriad of other possibilities.
All of the traditional gentoo installs, such as the handbook, would
benefit from simplification and the natural clarity that simplification
brings. Builds of things like simple standard gentoo-cluster-CI. Nothing
would preclude the adventuresome from building up
a traditional, highly customized install, for a specific needs such as
currently is the (handbook) practice. But additional gentoo installs
that are quick, streamlined and soot a specific itch.
That way a user, a proxy-dev or a dev could work on any and every aspect
of gentoo, perfectly isolated from other devs with a select group of
testers. Each team could maintain their build formulary very easily, and
others could provide the bugzilla feedback on that particular
fork/custom/project. Those bugs would be assign to the project
fork-team. Gentoo-proper would benefit being able to 'reap' the
benefits of a streamlined develop, deploy, test, refine, stabilize
efforts; and folks can each have their own fiefdom, whilst still sharing
gentoo-proper as we currently do. And bgo would be a default place to
seach out gentoo specific issue, both on gentoo-proper and these glep-70
projects. Of a separate bugs-engine for these projects
that is a companion to bgo, but separated, if that is better?
There are at least a half dozen folks that have done this, their own
gentoo-derived-distro, many were mainstream devs at some point. Why not
streamline and optimize that systems, to the benefit of gentoo-proper?
Gentoo proper dev testing could occur either before a project (glep 70)
fork, or afterwards as the benefits are tested and vetted for
introduction back into gentoo-proper. A polished
gentoo-cluster-CI semantic makes all of this immensely easier, imho.
Common ground between gentoo and it's offspring distros, could become a
very powerful platform, unique among distros, imho. Flag minimization
and freedom is a core need shared by all forms of gentoo, imho.
hth,
James
