Re: Packaging and installation
In message <20001023160622.A456@turbolinux.com>, Bodo Bauer
<bb@turbolinux.com> writes
>Eric S. Raymond (esr@thyrsus.com) wrote:
>> Nicholas Petreley <nicholas@petreley.com>:
>> > Instead, we should define an installation protocol that
>> > looks for programs and libraries within the filesystem
>> > itself in order to detect if dependencies are met.
That's what I think we need too ...
>>
>> Nick, I think this is a case where the search for perfection is far less
>> important that getting a solution in place that does 90% of the job and
>> can evolve to do 100%.
I'm not sure that it can ...
>
>I (as an ex Zenguin guy...:) agree with Eric. We have RPM and it works well
>in most of the cases. A 100% solution is too much of a dream to become
>reality any time soon. And quite frankly I don't know if I'd like to
>have one and only one package format. Competition is good and it drives
>technology (see Gnome/KDE... :).
You agree with rpm, yet you want to see competition in package formats?
How the hell do you reconcile those two contradictory statements?
>
>But one point that should be addressed is the use of RPM itself. Different
>distributions make very different use of RPM and often it's not compatible to
>each other. What ever happened to LANANA as name authority. Standards
>for package names, standards for spec files (i.e. how to handle
>architecture dependent stuff, how to deal with i18n...) could help a lot.
>The current LSB version needs to be more elaborate on those issues.
>Also how to handle versions and releases is an important issue within RPM
>which is still not addressed...
>
Which is why Nick and myself are strongly in favour of an API which
tells you WHAT IS PRESENT.
Who gives a damn whether a system is .rpm based, .deb based, or anything
else. If I've got an api defined which allows me to query/update the
package database, it means I can check dependencies, and it means that
as the user (should I care to) I can make a "make install" tell the
system that the package is there.
I gather there is now an interface that says "Package LSB version 1 is
installed". Good engineering says "solve the generic, let the specific
look after itself". WHY THE HELL HAVE WE SOLVED A SPECIFIC INSTANCE OF A
GENERIC PROBLEM !!!!!!!!
Lets define a standard api for querying/updating the package database.
Then all of this stupidity will go away. And as I said in the "Chapter
13" thread, it means that we could then define hardware as simply
"another package". The manufacturer provides a script that uses the
standard api to update the "installed packages" database and the
software can install appropriate drivers etc etc.
At present Nick is complaining about "either/or" ncurses, which means
even on a standards-compliant installation you can't guarantee an
ncurses program will run. The standard does not even mention X - it
needn't be there which means that no "user friendly" program can rely on
the standard - it's irrelevant to gui needs :-(
For $DEITY's sake, just provide an API that can tell any interested
program exactly what is available, rather than all this "standard
packages" crap!
--
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
Reply to: