Packaging and installation

[Jeffrey Watts]

On Tue, 24 Oct 2000, Nicholas Petreley wrote:

> No, I just wasn't specific enough. You're saying to use RPM package
> format.  And if someone wants to install the file on a Debian system,
> then they need to either use RPM (which simply doesn't work, since the
> RPM database doesn't contain all the necessary dependency information
> if that user has used any other system like .deb) or alien (which
> doesn't work, because alien is far from perfect and it screws up the
> installation at times.)

No, not at all.  We're not talking about using the command 'rpm' or the
"/var/lib/rpm/*.rpm" RPM databases at all.  We're talking about the RPM
file _format_.  As in how the files, dependency information, and scripts
are stored in a file.  That's it.

Each distribution vendor would provide a command, 'lsb_install', that
would be able to read the file, resolve dependencies, and install the
package either by simply extracting the files and running any scripts (on
a Slackware-like distro), or by installing it using the native package
manager.

This design is elegant in its simplicity.  It allows distributions to keep
their existing package management systems (all LSB participants will have
little difficulty working with this), is rather simple to implement --
alien already does most of what's needed so most distributions won't have
a hard time complying, and DOESN'T FORCE A STANDARD WHERE A STANDARD ISN'T
CALLED FOR.  I don't like using caps, but I felt it was important to
emphasize this.  Please don't mistake my use of caps as shouting.

We're the "Linux Standard Base", not the "Linux Standard Distribution".  
We're defining a baseline for _application compatibility_ and we're not
trying to define how distributions should do their housecleaning.

That's where the breakdown is.  'lsb_install' written by distributions and
using the RPM format is the most practical solution.  Defining and
implementing a new package API is not only impractical, but pointless.

Why do you think Debian still uses their packaging system?  Why does
Slackware not use one at all?  Because there's more than one way to do it,
and the Debian and Slackware folks feel that their way has advantages.  
And they're right.

The reason we have multiple distributions is that folks want choice, and
want to do things a different way.  Defining a far-reaching package
management API that is _required_ to be present and _required_ to be
functional is likely to prevent several distributions from joining the
effort.

Right now a distribution like Slackware could become LSB-compliant.  They
would simply make sure that their distribution was LSB-compliant, and
'lsb_install' would simply do it's thing.  That's because Slack assumes
its users are thorough enough to make sure that they aren't breaking
compatibility, and will do the homework necessary to not install
non-compliant software.  Distributions like Slack are NOT likely to become
LSB-compliant if we require them to do things like use a package
installation API that can't be reduced to what they are doing now
(tarballs).  They see no need for it, and they're correct.

ISVs will be fine with all this, because all they care about is whether
their software will work on any given distribution -- they don't care if
the user has broken their distribution by adding or removing necessary
software after the fact.  They won't like having to do the support, but
they already have to deal with this problem all the time on Windows, and
Windows is fairly well standardized.  User error will always be a problem,
and no standardization project will likely ever solve this.

> Then we need to expand the scope. Why has someone put an arbitrary
> artificial limit on LSB that it can only document what GNU/Linux
> already does?

Because this is what the scope of the project is and that's what the
principal participants want to do?  The LSB is not saying that there
aren't other standardization projects that can be done.

But it is important we don't try and take on EVERYTHING at once, in one
project.  We need to define the efforts needed, and assign resources.  
And I mean "we" as in the GNU/Linux community, not necessarily the LSB.
  
One of the goals of the LSB is to deliver its standards quickly, and we
are far behind schedule.  Increasing the scope cannot allow us to
accomplish our goals any quicker.

Look at the GNU Project for an example.  A HUGE project with a tremendous
task ahead of it.  After 16 years, it's still not done.  And it's not
really meant to be completely done, as the computer world doesn't stand
still and there will always be work to be done.

While that may be great for the GNU Project, where their goal is to
provide all the pieces of a Unix-like OS, it is a project completely
unlike the LSB.  The LSB wants to define a base, and it needs to be a
standard that can be put out on a regular basis that describes a compliant
system.  Its goal is documenting software and structure that's already
used and should be there so that 3rd parties can write software that's
portable.  Its goal is NOT to define the evolution of the Linux platform.  
Projects like the FHS are for things like that.

Remember, we all matter somewhat, but the opinions that REALLY matter are
the folks that have to do the hard work making their distributions
compliant.  This is not mob-democracy.  We can guide and influence
decisions, but there are some we cannot make.

As far as I can tell, the principal parties have spoken their minds, and
it's to use the RPM format and to not define a package manager or package
management API (I think we need a definitive answer from the Steering
Committee on this though).  This is not something we can just vote on.  
If someone can provide a different solution that better meets the needs of
ISVs and distribution vendors, they MAY change their minds and change the
scope to include these ideas.

I think the problem is that you're thinking "how can we improve GNU/Linux
distributions?".  That's not what we're doing here.  We're discussing "how
can define a common set of software that should be present on a system so
ISVs can write software that will run on any LSB-compliant system?".  All
the supporting work like defining RPM as the package format is a
supporting project, and not central to our goal.

Your ideas may have merit, but unless they are somehow addressing
something that isn't being addressed now by our choice of RPM as the
format, I'm willing to bet that the path of least resistance will prevail.  
Note that when I'm referring to "something that isn't being addressed", I
am speaking in the context of the current LSB scope.

Your argument is akin to asking the folks who are making the testing
suites to not only test for LSB compliance, but to also test for how the
system rc files are written.  Perhaps it may be useful to have
standardized rc files, but it certainly isn't useful in the context of
defining a base set of software versions so that third parties can package
software that is portable between compliant distributions.

> And before you object, note that it is not at all what LSB is doing.  
> FHS 2.1, for example, is something that none of the GNU/Linux distros
> do.  Yet we're (RIGHTLY) expecting them to change their distros to
> conform to FHS 2.1.  Why stop there if we can solve other problems,
> too?

FHS-compliance is simply a necessary pre-requisite for LSB-compliance.  
Note that the FHS is a separate project that existed before the LSB.  To
be LSB-compliant distributions MUST be FHS-compliant.  It's a requirement,
that's all.  The LSB makes this a requirement because it is needed in
order for the LSB to accomplish its goals.  That's all.  We don't go
farther because we don't need to.

Also, the participating distributions of the LSB have made great strides
towards FHS 2.1 compliance.  Red Hat, SuSE, TurboLinux, Debian, and others
have made great strides towards compliance and are active participators in
the FHS effort.

See the preliminary results from the new LSB-FHS Test Suite here:
http://www.linuxbase.org/test/results/

Remember, the LSB isn't a project aimed at forcing the distributions into
complying with its standards.  It's a project started by the distributions
aimed at standardizing a Linux Base so that ISVs can write software that
will work on all distributions.

> Then we need to explain to them why it is not only acceptable, but
> necessary.  And please understand that I'm not suggesting we dictate a
> package management system.  I'm suggesting we dictate a package
> installation protocol (or API, as it has been described elsewhere).  
> Distros can implement the program that uses the API any way they wish.
> There's a LOT of room to add value there.

I think that what you are talking about is forming a new project.  I
actually agree with you in many ways and think that your ideas have merit,
but they are outside the scope of what we are doing here.

I suggest that folks start a NGGLPAPI project, for Next Generation
GNU/Linux Package API.  Design a new package management API that works
better that what we have now.  Assuming you are successful and the major
distributions adopt it, I'm willing to bet you will see the LSB define the
NGGLPAPI as a standard.

Or start a project designed to guide the development of GNU/Linux
distributions.  A project that would try and move the technology
underlying GNU/Linux distributions forward in a progressive and
technically-superior direction.

Both of these projects have merit and are great ideas.  But they are NOT
what the LSB is doing right now.  We can argue this until we are blue in
the face, but I don't think it will go anywhere.

> Then we obviously haven't discussed it enough.

In your opinion, Nick.  ;-)

The nice thing about the whole Free Software movement is that folks can
disagree, fork, and move in different directions without it being a bad
thing.  It's good that all we are arguing about is the _scope_ of the
project, not so much on how it is done.

Even though I don't agree on your vision of the LSB's scope, it's not like
my opinion really matters.  :-)

I suggest that someone -- perhaps yourself, since you are good at
expressing ideas clearly -- should write up a concise request to change
the scope of the LSB project to include standardizing the package
management of compliant systems.  This then can be submitted to the
Steering Committee (Daniel Quinlan is the Chairperson) and we can get a
definitive answer on whether or not to change the scope to include these
ideas.

Since the purpose of the Steering Committee is to decide things such as
this, this hopefully will resolve this debate for good.

If they decide to change the scope, you will find I will support your
endeavors completely.

> Either is fine.  I get called a whole lot worse. ;-)

Hehe, I know the feeling.

Thanks,
Jeffrey.

P.S.  Please correct any factual mistakes present in my rather lengthy
email.  I do not profess to be anyone of importance -- I am just an
interested observer and I definitely do NOT know everything that is going
on.  Ignore the grammatical errors, I've edited this so many times I've
likely made many.  :-)

o-----------------------------------o
| Jeffrey Watts                     |
| watts at jayhawks.net         o-----------------------------------------o
| Systems Programmer         | "We should not be building surveillance |
| Network Systems Management |  technology into [Internet] standards.  |
| Sprint Communications      |  Law enforcement was not supposed to be |
o----------------------------|  easy.  Where it is easy, it's called a |
                             |  police state."                         |
                             |  -- Jeff Schiller, IETF                 |
                             o-----------------------------------------o