[OpenAFS-devel] DRAFT: New sysname standard

[Jeremy Katz]

--EVh9lyqKgK19OcEf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wednesday, April 25 2001, Derek Atkins said:
> Jeremy Katz <katzj@linuxpower.org> writes:
> > Unfortunately, all of these are somewhat nitemare-ish as far as
> > maintaining a set of symlinks in afs for binaries are concerned.  In a
> > lot of ways, it almost seems as though there needs to be a mechanism to
> > have a "canonical" sysname which could be i386_linux24_glibc22 or
> > whatnot, but also be able to have some sort of table of compatible
> > sysnames to try if there isn't the one you're looking for.  But I
> > haven't gone to see how non-trivial that would be to do yet and I'm
> > guessing it wouldn't be pretty :(
>=20
> You can certainly make a user-space 'program' that will take a list
> of 'compatible' sysnames and try them all.

And then you lose one of the primary advantages of @sys IMO.  Especially
if something like i386_redhat_62 were to end up being used, you're going
to end up with a ridiculous number of sysnames really quickly.  Also,
why shouldn't it be easily possible to have binaries compiled
specifically for i686 and also have an i386 version that could then work
on older systems.  If your sysname were i686_linuxFOO (completely
disregarding what foo is for the moment), i386_linuxFOO programs could
be run without any problem and if i686_linuxFOO didn't exist, it would
make sense to use things under i386_linuxFOO. =20

Heck, even if glibc versions are used per the original proposal, if
you're running glibc 2.2, it makes good sense to try glibc 2.1 binaries
if there's nothing for 2.2...  99% of the cases will work fine.

Jeremy

--=20
Jeremy Katz
katzj@linuxpower.org	| jlkatz@eos.ncsu.edu
http://linuxpower.org	| Developer, NCSU Realm Kit for Red Hat Linux
GPG fingerprint: 367E 8B6B 5E57 2BDB 972A 4D73 C83C B4E8 89FE 392D

--EVh9lyqKgK19OcEf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE65wJNyDy06In+OS0RAmmeAJ48r45uyxlYy8yQHu9q9WAh1ElvrACfZ/Gx
puszLbiE1cL4KEXt0xpXO/I=
=c6Jm
-----END PGP SIGNATURE-----

--EVh9lyqKgK19OcEf--