[lsb-discuss] Don't blame LSB and standards, please: was: Re: Fedora Plasma Product, feedback please
tytso at mit.edu
Mon Mar 31 23:06:29 UTC 2014
On Mon, Mar 31, 2014 at 03:27:22PM -0700, Russ Allbery wrote:
> "Jóhann B. Guðmundsson" <johannbg at gmail.com> writes:
> > The problem I'm trying to solve is unification across distributions and
> > applications which I though was clear and I thought this standard was
> > supposed to be solving
> I don't think it is.
> At least, as a distribution developer, my impression has always been that
> LSB is primarily aimed at providing a standardized platform that
> third-party commercial application developers can target and be relatively
> assured of being able to run on any Linux distribution. For the most
> part, the actual workings of the native packages of the distribution were
> out of scope, provided that the interfaces were available to third-party
> software of that sort after installing the lsb package.
That's pretty much the understanding most of us who started working on
the LSB lo these many years ago had. It was *not* about unification
across distributions, mainly because we understood very early on that
was a fools errand.
I mean, if you think you can convince Debian to be more like Red Hat
in terms of who their primary user base might be, administration
tools, etc. Or if you think you can convince Gentoo or Arch to be
more like Open SuSE, best of luck. We have had conversations over a
beer about such things before, and the the good news is that engineers
are pretty good at agreeing to disagree, and recognizing that
different customer use cases might cause different resulting designs
--- unlike the sort of e-mail dissing that tends to happen by fanboys
and fangirls. But it generally doesn't result in changes that lead to
unification, at least not as far as the big picture is concerned.
When (several years ago) we managed to convince Red Hat and SuSE to
ship the same stdc++ library (because the upstream developers screwed
up and accidentally introduced an unintentional ABI incompatibility),
we counted that as a major success. And it happened only because was
one distribution was much more willing to be flexible and to work with
us than the other.
> There are a few exceptions, of which the FHS is probably the largest, but
> they're exceptions. And even the FHS is not (at least in my opinion)
> suitable for adopting universally in its current form. Debian carries
> nine explicit exceptions to the FHS, and we're likely to add several more
> in the near future.
Yah. The FHS hadn't gotten enough love back when I was actively
involved, and it probably needs updating even more desperately at this
point. The main problem, as Russ has stated, is one of resources.
Someone has to volunteer to do the work to make the changes and gather
support for the changes, especially if it means working with the
distributions to encourage them to make some changes for the common
good. It takes a lot of time, and we have done that in the past.
Some distributions have been more receptive to this lobbying than
others, and at the end of the day, we do not have the power to force
distibutions to do anything.
> Every Linux distribution has its own internal process for standardizing
> how, say, packages will be managed, where files should be installed, how
> integration with the rest of the system should be done, and so forth. I
> think it is extremely unlikely that you would be able to achieve
> widespread standardization in those areas precisely because variation in
> those areas is *why* people start new distributions. In other words,
> doing those things differently across distributions is considered a
> feature by the people working on those distributions, not a bug.
> If you wanted to work on standardization and documentation of how, say,
> Debian (and to a lesser extent Ubuntu) packages are laid out, maintained,
> and integrated with the rest of the system, the appropriate forum is
> Debian Policy, not LSB. Likewise, if you wanted to work on similar things
> for Fedora, I'm sure Fedora has their own separate working group on the
> LSB, at least in my view, is much more about identifying and documenting a
> shared, common set of features (which may or may not be enabled by
> default; you may have to install an lsb package to get them) that third
> parties who do not want to participate directly in the process for that
> distribution can rely upon, and that distributions can provide if they
> want to enable third-party applications.
More information about the lsb-discuss