Re: Standardizing the install Package...
Mik,
You do point out an area that could use some innovation. It would be
good to be able to have an installation tool that can process different
formats, including tar.gz, and maintain the registry or db properly.
I'd like to clarify what is currently in the spec though. Thus far,
the LSBs approach is to specify the file format of the package (ie rpm-like),
and to simply state that a conforming distribution will have some tool
available that can process that file format. We are not specifying what the
interface to that tool is, or how it works. What you suggest is one possibile
implementation of that system.
There is more than one good packaging system implementation out there
today. Presently, this is an area where distributions differentiate themselves.
Limiting the specification to the file format of the package meets the need of
having a common distribution format for applications, while not interfering
with a distribution's ability to innovate in the package management area.
On Thu, 3 Sep 1998, Michael H. Voase wrote:
> Sorry for not lurking in the backround but I feel the need to bring a
> small point to attention ...
>
> After reading the current preliminary framework for the LSB , I happened
> to notice that the issue
> reguarding package standarization was brought forward by Stuart Anderson
> . The specification
> tentatively points toward the rpm format as a standard and this will
> probably work well . However
> the rpm system introduced the concept of a program registry ( on default
> Red Hat systems it is in
> /var/lib/rpm )to linux and while this is very useful it does not lend
> itself well when one is installing
> non-rpm packages . To settle on rpm style of program registry will
> benefit linux , expansion of
> that registry so that other package formats (ie tar.gz and .deb ) can
> declare themselves to this
> registry would go a long way to providing a basis for standardizing
> package installation . For
> example if source tar.gz package included and small description along
> with a list of dependencies
> and programs installed by the Makefile while rpm provided a method
> whereby
> this information could be included into the rpm registry , then a decent
> dependecy and installed
> package database could be built that truly reflected the state of a
> linux machine .At this point in time
> if I install a tar.gz source or binary package in my R.H. system , I
> have to manually adjust my
> program registry to reflect that the package is present . To install an
> arbitrary rpm on my Caldera
> system is an absolute nightmare . It can be worked around , but its
> painful .You may notice
> that this is a concept which M$ have used to gain a great deal of
> fuctionality between M$ and
> non-M$ software. (When they have allowed interaction to occur ). By
> applying the same
> basic principal to linux , ie , a standard program registry which can be
> manipulated by a variety
> of installation formats , a vendor /developer can select whichever
> package format suits their
> developement methods while implementing a standardized registry method .
> Its a topic that I feel
> is worth further investigation .
>
> My 2c worth . Cheers Mik Voase . (goes back to lurking in the
> backround...)
>
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
>
Stuart
Stuart R. Anderson anderson@metrolink.com
Metro Link Incorporated South Carolina Office
4711 North Powerline Road 105 Fox Ridge Run
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.938.0283 voice: 803.951.3630
fax: 954.938.1982 SkyTel: 800.405.3401
http://www.metrolink.com/
Reply to: