SCIENTIFIC-LINUX-DEVEL Archives

March 2006

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Axel Thimm <[log in to unmask]>
Reply To:
Date:
Thu, 30 Mar 2006 22:39:40 +0200
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (1350 bytes) , application/pgp-signature (196 bytes)
On Thu, Mar 30, 2006 at 01:09:51PM -0600, Troy Dawson wrote:
> Well, I wasn't thinking that atrpm's and dag is going to break 
> compatibility, but for some admin's that's just the first stop.  They 
> then go to fedora-extra's, and then down to fedora core.  That is why 
> I'm asking, just where should we draw the line.  Or is there a firm 
> line, and maybe just have guidelines.

I understand what you're thinking of. In that case I would define

SL3, SL4, FC<N> etc are all *not* compatible. The very least of
compatibility of package ensembles would be to be built on the same
glibc (series). Of course on can talk about src.rpm compatibility and
there most of them would turn to be compatible again.

In general I'd require for something to be (binary) compatible to
SL<N> to have been built on SL<N> or a subset of SL<N> which RHEL<N>
is.

E.g. a package from dag for fc3 is not compatible to sl4 even though
these two distributions are quite similar, but if oyu rebuild it from
src.rpm then it will be. Of course for dag you don't need to rebuild,
but just to give an example.

No distribution forger should take packages cross-distribution w/o
rebuilding. Maybe that's part of the policy you want to assemble.

(there are some exceptions to the above for packages that never sense
the environment like firmwares/fonts and similar).
-- 
Axel.Thimm at ATrpms.net


ATOM RSS1 RSS2