[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Lsb-CommonPackaging] RE: extension of lsb packages

On Tue, Mar 05, 2002 at 02:37:34PM -0800, Wichmann, Mats D wrote:
> > I think the main problem here is that the taskforce was attempting to
> > create a standard for packaging.  What really needs to happen here is
> > for the Linux Community (and perhaps even other groups like Sun, HP,
> > IBM, HP, Apple, and *BSD) to come up with a BETTER packaging solution
> > than what we have. 
> Been done, and failed. IEEE 1387.2-1995 was such an effort.
> Someone told me the standard is now formally withdrawn.
> My view from very far outside that effort was that it pretty
> much was a best-practices effort, taking the main concepts
> from the HP SDU (swpackage) and SVR4/Solaris pkgadd systems 
> and attempting to answer the problems that had arisen in practical 
> use with both systems (two of which were patches and repairs), 
> with somewhat of a nod to a few other approaches.  I'm sure 
> someone who was involved will have plenty of war stories and 
> reasons why it went nowhere, if any of the participants happens 
> to be listening here.
> My suspicion is that it was a solution not driven by sufficient
> motivation to actually implement - i.e., $$$  Much as the sysadmins
> of the world wish it might be otherwise, the whole planned POSIX 
> sysadmin series seems to have fallen into disrepair, and sysadmin
> remains a roll-your-own frontier.
> One wonders if it's worth trying again?

  IMHO, no. There is even less cash from those large vendors to pursue
such an effort. It's also unclear there would be any incentive from them
to redo it. And from a smaller perspective, in the Linux world we already
have a strongly deployed existing practice, and I don't see the gain of 
trying to rebuild from scratch in this smaller set of players. See my other
post for the problems associated with such approach.
  We are running a low cash, minimally disruptive standardization effort,
the LSB and the players behind it can't afford a different approach.


Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Reply to: