[lsb-discuss] Some thoughts about the recent packaging discussion

Theodore Tso tytso at mit.edu
Sat Mar 1 22:21:39 PST 2008


On Sat, Mar 01, 2008 at 11:46:15PM +0000, Alan Cox wrote:
> Except you've created a non standard that seems designed to make it less
> likely people will solve the real problem and also causes security
> problems down the line because most vendor provided installers have not
> been audited properly, do not fit into things like SELinux rules (the
> rules secure sites run to say things like 'random package installing is
> bad'). 

The sad fact of the matter is that ISV's that have these issues have
just already told their customers.  "Disable SELinux and try again."
Even when I've talked to people who are designing huge Linux
installations on warships, in many cases it's simpler to disable
SELinux and avoid running MLS.  (They just have separate sets of Linux
systems running at Secret, Top Secret, NATO Secret, etc., and have
High Assurance Guards which as separate, highly secured systems that
control the flow of information between networks running at different
levels of classification.)  So there exists rational designers, even
those who are working on systems which have to protect U.S. government
classified information, who have decided that SELinux is Just Too
Painful.


The main issue though is that most ISV's need to make their software
work on multiple operating systems, of which Linux is just one, and
they aren't particularly interested in having documentation (both text
and screenshots) which works one way for Linux, and works another way
for everyone else.

So these ISV's *are* going to use either their own home-grown
text/graphical installers, or they will use something like
Installshield for Java.  That's *just* the reality.

We could ignore the issue, which is a perfectly sensible choice for
the LSB and for each distribution.  Such applications exist today, and
they will exist tomorrow, and they applications that do this don't
violate the LSB rules today.  It's just that once installed, they
can't be uninstalled unless there is an application-specific uninstall
program/script.  

So the other choice is the Berlin API, which had gotten consensus from
representatives of the Red Hat and Novell folks who maintain their
respective distro version of RPMs, as well as folks from dpkg, simply
made it possible for these applications to be uninstalled.
Unfortunately, no one stepped up to actually implement the silly
thing; that's what we are proposing to do now.

If a particular distribution, decides not to include the patches which
implement the Berlin API.  I happen to think it's a net positive for
such a feature to exist, but it truly won't be the end of the world.
It may be that distributions that suport the Berlin API proposal will
have a competitive advantage over those that do not; but each of them
can decide on their own what they want to do.  It's not something
which I think the LSB should require a distribution to do; it is
simply an opportunity for distributions to provide an added value over
that which other operating systems would not have today.

> So instead of insulting Debian people how about making the supporting
> tools for rpm format binary packaging simply irresistable. For the LSB
> binary side format that means stuff like "zip2rpm" and other things which
> are anathema to source/binary control as rpm is used in free software,
> and adding pointy clicky "packageme" tools plus makefile scriptable bits
> for "add scripts, set description, pack tar file into rpm and ship"

If people want to work on that, they should feel free to do that.
>From the ISV's that I've talked to, that isn't going to change the
equation, however.  It's not just the effort in creating the RPM's,
it's documentation effort and the cross-OS compatibility issues.  It
may come as a shock to some, but Linux isn't the only OS out there,
and many commerical ISV's do support more than just Linux as an OS....

    	 	    	     	     	  - Ted



More information about the lsb-discuss mailing list