Re: Packaging and installation
On Wed, 25 Oct 2000, Nicholas Petreley wrote:
> Yes, I'm hearing a lot of this. LSB was not meant to do this. LDPS
> was not meant to address that. These are artificially imposed
> limitations - and what you go on to say implies that we're imposing
> these limitations so as not to upset the distributions.
No, no, no. Please do not color my text. Nobody here is trying not to
"upset the distributions". I don't know if you know the folks involved in
the LSB, but most of them represent a distribution or ISV. For the most
part, the LSB _is_ a vendor interest.
There's no conspiracy to only do what the distros want. There's no hidden
bias in favor of them. The reason is that this kind of standardization
effort is designed _for_ the benefit of ISVs and distributions. There is
a bias, and it's out in the open. The goal of the LSB is to serve the
interests of ISVs and distributions. It's not designed to be for the
benefit of users, though most of us feel that enabling ISVs to make
software that will run on many distributions will help users as well.
You are asking for a different animal. There's no resistance here to that
kind of standards effort. However, this standards effort is not doing the
kind of standardization you want. Perhaps in the future, on a future
spec, it will, but not right now.
So you have two choices, assuming you make a formal proposal to change the
goals of LSB 1.0 ,and it fails (which is likely) -- you can work with us
to finish what we are doing, or you can start another project whose goal
is to do address needs of users. Either way, continued argument is
pointless. Let's move on.
Note that I am NOT saying "don't bother submitting your proposal, it won't
pass anyway, so give up". I highly suggest you do it, so that we can put
this to rest. It would be a tremendous waste of our time if we went
through all this discussion just to have the issue dropped. I for one do
not want to see this argument come up again.
As far as anything else goes, please try not to read things into what I've
said and take my thoughts at face value. I've spent a lot of time
composing these messages, so they should represent my thoughts fairly
well.
> Regardless of how you explain the reasons for imposing such
> limitations, they ARE arbitrary.
One could say that every project limitation is arbitrary. Projects
involving groups of people have to have limitations in order for them to
be completeable, and often the dividing line isn't technical, it's
temporal.
The Linux kernel is a perfect example. Feature freezes are extremely
arbitrary from a technical perspective. Why are they necessary? If Linus
didn't impose them, a new stable kernel would never get released.
> And I hope you realize that whatever LSB decides necessarily puts a
> bias on the future of Linux if indeed the distros follow LSB.
For the most part, the LSB _is_ the distributions. If they don't
implement it, well then they shot themselves in the foot and the LSB will
die. Considering that Debian, Red Hat, Mandrake, SuSE, TurboLinux, and
others are working towards compliance with this standard (and are actively
developing it), I don't think there will be a problem. If they don't
comply with their own standard, the market will weed them out.
> If LSB decides RPM is just fine only for LSB-related
> programs/libraries/etc, then what we are doing is pushing the distro
> world toward RPM for everything.
Nick, I don't know where you've been, but RPM _is_ the standard. Most 3rd
party software out there that is packaged is packaged for RPM. The
current state of affairs hurts the smaller distributions. The LSB would
_improve_ the state of affairs by allowing ISVs to develop software that
would run on more systems than just Red Hat. This is a good thing for
everyone (including Red Hat).
> If RPM is not a sufficient solution for everything (and IMO it is not,
> at least not by itself), then we have done a disservice to all of
> Linux simply because we didn't want to go beyond our arbitrarily
> imposed boundary.
I don't think you meant to say "is not a sufficient solution". RPM is
most definitely a "sufficient solution", as most GNU/Linux distributors
are happily using it to package their products. The fact that it _works_,
means that it's _sufficient_. I think you probably meant more like "is
not a perfect solution", which is certainly possible. This is the root of
the problem. Provide a solution that _works_, and is _completed_, and
maybe we'll give your ideas more attention.
Think "a bird in hand is worth two in the bush". Also applicable is "the
grass is always greener on the other side".
Jeffrey.
o-----------------------------------o
| Jeffrey Watts |
| watts@jayhawks.net o-----------------------------------------o
| Systems Programmer | "You know that saying, 'To everything |
| Network Systems Management | there is a season'? Well I'm still |
| Sprint Communications | waiting for Loud Neighbor's Cat Season |
o----------------------------| to open." |
| -- Paul Keifer |
o-----------------------------------------o
Reply to: