Panu Matilainen writes: > [pmatilai@weasel ~]$ lsb_release -a > LSB Version: 1.3 > Distributor ID: FedoraCore > Description: Fedora Core release 4 (Stentz) > Release: 4 > Codename: Stentz > > ..is as portable as it gets AFAIK. You didn't mention what exactly are > you using the info for so difficult to say if that's the best way to > accomplish that. My goal here is the setting of variables in Makefiles to automagically determine the right place to install rpm's in a yum repo layout on arbitrary build hosts for many supported architectures. This is somewhat apropos of my earlier post today about using homebrew filesystem structure as an informal way of resolving a set of variables that vary over some systematic set of values from system to system, when building a multi-distribution repository, for example: distribution/releasever/basearch [Centos,Fedora,RHEL,SuSE,...]/[[0-9][.][0-9][0-9]...]/[i386,x86_64,...] in place of either XML tags in an arbitrary structure or at LEAST a well defined set of uniformly extractable variable values used in a filesystem layout like the one above. The particular choice of terms in this is somewhat arbitrary -- only $releasever and $basearch are parsed "for you" in yum and there is no consensus on the right way to order these in a repo tree (AFAICT from the repos I use or have used). If lsb_release is the way to go, it looks like a "well-formed repository path" might should be FedoraCore/4/i386, not Fedora/4/i386, as the former can be extracted from a standard tool (as can e.g. the i386 from uname -i) while the latter -- well, one person might use fedora/4/i386, another might use Fedora/4/i386, another might shoot for FC/4/i386. As I said then, if we could agree on either a common/standard/portable layout OR a common/standard/portable way to extend the variables available server side and client side, we could reduce the amount of human work required to sensibly organize a repository and automate many of the build/maintenance tasks (such as make install2yum directly into a repo image on a build host). In the meantime, I want to try hard to make this the LAST time I modify my personal Makefile templates to accomplish this sort of task. So the output of lsb_release -i as in: rgb@lilith|B:1172>lsb_release -i | sed 's/.*:[ \t]*\(.*\)/\1/' FedoraCore it is. In fact, rgb@lilith|B:1178>echo `lsb_release -i | sed "s/.*:[ \t]*\(.*\)/\1/"`/`lsb_release -r | sed "s/.*:[ \t]*\(.*\)/\1/"`/`uname -i` FedoraCore/4/i386 is then a completely portable and automagical way to build a repo install path that correctly represents the parseable hierarchy. This leaves only repo "level" or "name" as an uncomfortable variable known in a repo conf but not specified at the path or tag level on the server. If we all agreed that the "right way to do this" is either: name/distro/release/arch or distro/name/release/arch (both of which are in fairly common usage) then life would become somewhat better. I have no strong preference, but note that names are more likely to be a user/repo-builder choice -- a fact reflected in the [name] being used as the primary identifier of a repo in yum -- and so the former seems marginally better than the latter. If either one were adopted, then a repo description could be reduced to (for example only): [name] baseurl = http://my.repo.host/yumrepo gpgcheck=1 gpgkey=http://my.repo.host/yumrepo/NAME-GPG-KEY where BY ASSUMPTION the actual repo path is (e.g.) http://my.repo.host/yumrepo/name/FedoraCore/4/i386 if those match name (defined above in the repo description), $distribution (set using the above) $releasever (set using the above) and $basearch (set using the above). This one repo description would be portable -- if my.repo.host supported Centos, FedoraCore, RedHat, SuSE -- as long as my repo layout followed the rules, one repo file would fit them all and one set of scripts or makefile snippets would help maintain them all. Even without the rigor, just adding $distribution (set using the above) and $name (derived from [name]) would permit baseurl = http://my.repo.host/yumrepo/$distribution/$name/$releasever/$basearch to be pretty darned portable, while still letting people pick and choose order and name if they want to do things the hard, non-portable way. rgb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.dulug.duke.edu/pipermail/yum/attachments/20050919/abf9f702/attachment.bin
