Re: Packaging and installation
"Anthony W. Youngman" wrote:
>
> In message <[🔎] 3AF8AA93.65FE7937@optushome.com.au>, Glenn McGrath
> <bug1@optushome.com.au> writes
> >Jeffrey Watts wrote:
> >> > 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).
> >>
> >
> >Sorry to drag up this old thread, but this issue isnt going to go away
> >by ignoring it.
> >
> >You (and the LSB) are suggesting that RPM should be the default package
> >format seemingly on the basis that its more widely used.
>
> And the format adopted by the LSB is *NOT* RPM, but a restricted subset
> thereof.
"package format" != "package installation and maintenance utilities". The
package format is the common currency of "Here is an archive of stuff to
install".
The utilities that do actual package installation and maintenance are
installation specific and mainly unspecified so far. I intend to specify
command lines and leave more than enough room for them to be implemented as
wrappers around the local native packaging systems.
I personally am working on wrappers for installations on dpkg systems as my
proof of concept reference implementation
> >People arent going to change package formats to something they consider
> >inferiour, or as flawed as their curent system.
>
> And the distros will almost certainly ignore the LSB as far as their own
> programs are concerned. Why should they be bothered? The main aim of the
> LSB at present is to ensure that binary-only packages will install and
> run successfully.
I *hope* distros will ignore the LSB as far as their own distributions and
distro specific programs are concerned. We have to smack down the idea
that "If it's packaged in a RPM package, it will install on any rpm
system." Cross release installs are always a crapshoot and --forcing
things just makes it worse.
The problem here is not that the packaging format is incompatible, but that
the compatible packaging leads one to assume that the software installed
will work on any system that supports that packaging format. The
dependencies are part of the attempt to enforce the requirements of the
software but those are release specific and (rightly) prevent installation
without user intervention.
Of course the user's common intervention is to --force things and that has
about the same amount of success as installing a light bulb with a hammer.
Part of the LSB-LCD packaging "standard" is an explicit dependance on the
LSB execution environment so that "Requires: LSB" actually means something
across all distributions and --force will be explicitly deprecated. Maybe
we shouldn't even have such a command line option!
> >If there is a clearly superier packaging system then the LSB should
> >support that and that alone, if there are number of packaging systems
> >that each have different flaws and benefits then the LSB should
> >recognise all these different packaging systems as having a valid
> >purpose, but recognise that they are not ideal.
>
> Which is why I am pushing for an api to interface between install
> programs and package management databases. But seeing as the aim of the
> LSB at present is to standardise what is already out there, this is not
> under consideration for LSB 1.0 :-(
> >
> >I dont see how the LSB can ever succeed if it is based on a popularity
> >contest rather than technical merit.
>
> And it can't succeed by permitting incompatible alternatives, either.
But a big enough carrot (application foobarxyyz now works on LSB compliant
systems! Yay!!!) and sysadmins will at least try the stuff out. Of
course, some upstream may actually start developing against the LSB
themselves. Then LSB packaging is a logical follow on and ditributions may
no longer have to package every major open source projects themselves.
> >The LSB is shooting itself in the foot by alienating non-RPM supporters
> >
> And by trying to accommodate both deb and rpm it would be shooting
> itself in the head :-( The whole aim is to support commercial vendors,
> who do NOT want to be presented with two compatible alternatives.
An non-RPM supporters alienate themselves by not reading the whole story.
Changes in wording will be needed! Patches will be appreciated.
> Just to keep you happy, it is under consideration that both deb and rpm
> might be consigned to the scrap heap. It's just not practical to address
> that at this point in time.
>
> >Glenn
> --
> Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
> HEX wondered how much he should tell the Wizards. He felt it would not be a
> good idea to burden them with too much input. Hex always thought of his reports
> as Lies-to-People.
> The Science of Discworld : (c) Terry Pratchett 1999
--
Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation
albertd@corel.com (613) 728-0826 x 5318
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "postmaster@umail.corel.com".
The poster's email address is "albertd@corel.com".
Reply to: