Packaging and installation

[Wade Hampton]

Evan Leibovitch wrote:
> 
> Is nobody else astonished that something so fundamental a standards issue
> as packaging formats, that was first debated the moment the LSB started
> more than two and a half years ago, is still being argued? This group has
> made so little progress in that area that a call to practically start from
> scratch is still taken seriously.
> 
> The problem is not that the RPM approach doesn't (or, more correctly,
> can't be made to) work. It's that this group has never reached a formal
> consensus/vote/decree/whatever on a packaging architecture. Had it done so
> ages ago (as Bodo suggests), resources could have been allocated to first
> draw up an RPM spec that would have at least had all the RPM-using distros
> on the same page. Debian programmers would have had an unambiguous target
> to parse. Efforts such as LANANA could have been accepted as a formal part
> of the LSB; having done that, this group could then address RPM's
> deficiencies at a later date.
VERY GOOD!

I suggest we take a vote.  The options are RPM or DEB?
Once the vote is taken, the result would be the standard.  All have 
pro's and con's.  Once an existing format is agreed upon (say in 1
week -- put hard time limit on it!), then address the shortcomings.

Once the shortcomings are addressed, do the standard for the format.

I agree RPM has some issues (e.g., when SW is installed from tarball
and not being seen by RPM).  However go to a Windows box, find a 
typical .exe or .dll and try to find who made it, when it was built,
when it was installed, what package it belongs to, etc.....  

We have some GREAT technology.  We can all agree to disagree, however
we have to go forward, somehow.

> 
> This step still can and needs to be done. Otherwise, the LSB will still be
> arguing packaging formats two years from now, while the rest of the world
> moves on without it. How relevant does the LSB strive to be?
LETS DO A VOTE ASAP!
> 
> Nick's core complaint about the yet-unformalized status quo was:
> 
> > if you install anything that a program needs via any other method
> > besides RPM, then RPM will consider dependencies unresolved...
> 
> Well, duh. If you make something a standard and users break the standard,
> then dumb results will follow unless the users know what they're doing.
> Creating a standard designed to anticipate how people will break it seems
> hardly worth the bother, especially if it means dragging out the decision
> to actually *have* a standard even longer.
RPM does what it was set out to do.  If we wish to permit external
installs, there should be a hack to /usr/bin/install or a program to
allow external sync with the RPM database.  These are EXTENSIONS 
of RPM.  

> Allowing for a manual way by which admins can manipulate the RPM database,
> to allow a scriptable way to announce the existence of capabilities
> installed outside of the RPM system, may be a reasonable compromise. This
> is workable so long as the RPM standard itself is well defined.
I agree.
> 
> In the meantime, how much longer must this core issue remain unresolved?
Can we take an informal vote on this mailing list?

MY VOTE IS FOR RPM 

Cheers,
-- 
W. Wade, Hampton  <whampton at staffnet.com>  
On July 8, 1947, witnesses claim a spaceship with five aliens aboard
crashed on a sheep and cattle ranch outside Roswell, New Mexico.
On March 31, 1948, nine months later, Al Gore was born!