Re: Noarch Naming Scheme
Axel Thimm <[email protected]> Tue, 31 Aug 2004 10:07:15 +0200
| Newsgroups | gmane.linux.redhat.rpm.atrpms.repo-coordination |
|---|---|
| Message-ID | <[email protected]> |
--===============0930682237== Content-Disposition: inline Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jeff, On Tue, Aug 31, 2004 at 08:00:58AM +0800, Jeff Pitman wrote: > My noarch packages will work on all distributions, I will be dropping=20 > the DISTTAG. Are you sure python3 or something else in the future will still be compatible with the same modules? What happens when/if arch-independent stuff moves to /usr/share etc. > But, the REPOTAG doesn't make sense by itself either. Why? You can use foo-works-on-every-distro-1.2.3-4.myrepo.noarch.rpm The repotag is only for identifying the package's origin. As such it is also rather optional, of course. > So, currently, I just have a plain noarch there. From an apt/yum > perspective, the repository is "Python 2.3" instead of "Fedora Core > 2" or whatever. So, I could possibly use a DISTTAG of "py2.3" or > something. >=20 > What are your thoughts on what should be done here? The latter sounds very good, but there may be a problem for python package linking against glibc etc. Suddenly you get dependencies to the underlying distro. So the above would work for noarch, but not for non-noarch and then you get multiple naming schemes. And worse of all, what happens when a packages starts up noarch and then gets some C written optimizations and needs to be renamed from "py2.3" to "rhfc3" (that would work by luck, but you get the idea)? There are only very few distro-independent packages like firmware, fonts or skins. But if you know that you will be supporting only the latest possible python with some package, so that you don't get to compare packages with the same buildid but different python builds, you can skip the disttag altogether. The disttag's main purpose is to ensure proper upgrade paths for concurrent builds. --=20 Axel.Thimm at ATrpms.net --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBNDGzQBVS1GOamfERAplEAJ9P/gbsVSrW2f7XB5nS2eW6dHerUwCfY0jU AwQLot39RLdLaSP07Q9zLQg= =IgFQ -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- --===============0930682237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ repo-coord mailing list [email protected] http://lists.atrpms.net/mailman/listinfo/repo-coord --===============0930682237==--