package formats (was Re: RH and GNOME)
On Wed, Jul 22, 1998 at 10:06:31AM +0100, Philip Hands wrote:
> Enrique Zanardi <ezanardi@ull.es> wrote:
> > So there are (at least) two cons, and I still don't see any pro. I ask
> > again : what's wrong with alien? Why do we need a * unified package
> > system?
>
> Oh, that's easy.
>
> Commercial software vendors want to be able to add one port to their port
> list, and be able to tick off linux as a whole. If that means that they
> produce, for example:
>
> oracle_8.0-1_i386.lsb
>
> and then their job is done, great. If you tell them that they've got a
> choice, or that they have to produce one for each distribution, they will be
> significantly less happy.
I agree they won't be happy if they have to produce one package for each
distribution, but I can't imagine a vendor being sad because he can use
wichever tool pleases he most. That's what I've been preaching since the
beggining of all this LSB stuff.
The LSB must define a minimum set of functionality a packaging format must
support (pre/post scripts, dependencies, ...) and we (the Linux
community) must work on translators between formats. That way the vendor
can package its products using RPM or DEB or SLP or whichever format he
likes/knows/makes-him-feel-dizzy, and we all will be able to install it
in our Debian distro, or our RedHat distro, or whichever distro we are
using.
Else, a vendor will have to use rpm, even if he knows dpkg and its tools,
even if he uses Debian to do its development, even if he knows dpkg is
the best package management system under the sun. Is it a good solution?
Is it the best solution?
> In my opinion, many commercial vendors would find both .rpm and .deb too
> complicated to build, so we should go for a system that is capable of dealing
> with something that is little more than a .tar.gz, as a bare minimum.
It's not the package format what makes a deb or a rpm complicated. It's
the functionality. Is trivial to type "dpkg-buildpackage -rfakeroot", but
you have to write the pre/post scripts, the changelog file, the control
file, the rules file... AFAIK, is not easier for RPMs. And there's no way
to avoid it if we want the package to have all that useful information
about dependencies and stuff. It doesn't matter if the building tool does
a "tar -cvzf ../foo debian/tmp/" or uses the cpio equivalent, one must
build debian/tmp in advance.
[...]
> One possible approach would be to allow vendors to do what they like under
> ``/opt/vendorname'' and then have the installer check for various
> things, like the presence of ``/opt/vendorname/bin'' and use an update
> alternatives style mechanism to insert the contents into the path.
>
> Allowing /opt/vendorname/packagename as an alternative would probably be a
> good idea too.
>
> It should also support a more integrated approach, similar to .deb/.rpm for
> the vendors that are competent enough to actually understand packaging, and
> want to take advantage of more advance features (pre/post-install scripts etc.)
>
> Cheers, Phil.
>
> P.S. Shaya, this might be worth a mention on the base-eng list when
> the subject is next allowed an airing.
I fear the LSB is going to mandate the use of rpm (the program) to help
those poor ISVs of the world. If they are not going to use the "no
standard package format, just functionality+translators" approach, I wish
at least they choose to define the package format only, and let us use
whichever tool we like best to build/install/manage it.
--
Enrique Zanardi ezanardi@ull.es
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: