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

Re: PROPOSED: 32/64 bit coexistance



Hi,

        [Massively trimmed the CC list]

>>"mikem" == mikem  <mikem@cyber.com.au> writes:

 mikem> Wichert Akkerman wrote:
 >> 
 >> Previously Oliver Paukstadt wrote:
 >> > I think if the package manager could solve our
 >> > problem, we should solve the problem in a clean way and not have /lib
 >> > pointing to /lib32 or /lib64 depending on an existant compatibility
 >> > architecture or not. Great standard. ;-/
 >> 
 >> Horrible standard. And rpm is not the only way to distribute,

 mikem> However, it is the Linux Standard Base recommended way of distributing
 mikem> software. Whether .deb or tgz is `just as often used' is *highly*
 mikem> statistically debatable (e.g., by looking at Netcraft surveys and other
 mikem> statistical studies).

	I was under the impression that the recommendation was for 
  (a) the archive file format (i.e., the contents of the .rpm file), and
  (b) A specified base level subset of package manager functionality
      as embodied by a specific version of rpm?
 

	The significance of the second part is that it allows for the
 underlying native package manager to be anything at all, as long as
 it provides a compatibility layer.  Changing the base line shall
 need to be evaluated against the feasibility of implementation on the
 various participating distributions.

 mikem> Seeing how much of the packaging system debate is not actually based
 mikem> around packaging systems, but higher level considerations and tools
 mikem> (e.g., APT, up2date, and other tools which aren't packaging systems but
 mikem> rather live on top of them), or policies, Linux standards should be
 mikem> build upon this previously debated and set packaging standard, and try
 mikem> to accommodate deviations as best as it can.

	I am given to understand that part of the underpinnings on the
 compromise of the packaging standard was it allowed us to present a
 simple, easily understood requirements set, without trying to force
 the straight jacket of a packaging system on all distributions.  This
 allowed the LSB to be a pan-linux standard -- an attribute that we
 should be loth to loose, I would think.

	I would agree with your statement, with the caveat that the
 accepted standard was not RPM in general, but a specific version of
 RPM, with a frozen feature set.

	manoj
-- 
 Against his wishes, a math teacher's classroom was remodeled.  Ever
 since, he's been talking about the good old dais.  His students
 planted a small orchard in his honor; the trees all have square
 roots.
Manoj Srivastava   <srivasta@acm.org>  <http://www.datasync.com/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: