There's a bit of impedance mismatch with the way we deal with bootstrapper and general binary management of repos. I think we need to agree on some standards (and of course implement them) for both consistency and reproducibility.
For example, if you look at http://repo.erlware.org/pub/5.5.5/ you'll see: i386-apple-darwin8.10 i386-apple-darwin8.11 i386-apple-darwin8.9 i386-apple-darwin9.0 i386-apple-darwin9.1 i386-unknown-freebsd6.2 i386-unknown-openbsd4.1 i386-unknown-openbsd4.2 i686-pc-linux-gnu-glibc-2.3 i686-pc-linux-gnu-glibc-2.4 i686-pc-linux-gnu-glibc-2.5 i686-pc-linux-gnu-glibc-2.6 powerpc-apple-darwin8.10 powerpc-apple-darwin8.11 powerpc-apple-darwin9.1 x86_64-unknown-linux-gnu-glibc-2.3 x86_64-unknown-linux-gnu-glibc-2.4 x86_64-unknown-linux-gnu-glibc-2.6 Contrast that to our bootstrappers (i.e. base faxien install): faxien-launcher-i686-Linux-V6.sh faxien-launcher-x86_64-Linux-V6.sh faxien-launcher-i386-Darwin-9.4.0-V6.sh A couple of questions immediately show up. One might be, if I get the x86_64 build of faxien launcher, will that cause me to upload binary packages for x86_64....glibc-2.3, 2.4 or 2.6? Another might be, if I get the Darwin-9.4.0 version of the launcher, will that generate (or use) binaries from i386-apple-darwin-9.1? Another bit of trickiness here is that when faxien seems to get most of the information not from the _running_ machine, but the machine that the version of erts was built with. So ultimately what we're seeing with this proliferation of binary packages is reflective of the various platforms on which people have built their version of erlang. This means, for instance, that I may have a version of erlang built against glibc 2.3, running on a machine with 2.7 -- and if I build a binary package specific to that glibc, it will get uploaded to the repo under glibc 2.3! (I know Martin has identified this as an issue, but figured it was worth pointing out in full context). By and large, the platform stuff really doesn't matter for pure erlang apps -- they'll just drop into Generic and everyone is happy. But recent enhancements to faxien now permit it to more accurately identify binary packages, so there _will_ be more binary packages that we'll have to deal with. And if we really want to nail down support for C-based drivers, we'll need to sort this all out in some sane way. I've done a little bit of research and it would _appear_ that glibc version isn't as critical as I originally thought -- at least not for most erlang drivers. If you build against glibc 2.3 it will run fine on 2.7 -- indeed if you look at the symbol table, the reference is to /lib/libc.so.6 -- no mention of 2.3 or 2.7. I don't know if that's a universal, but I suspect that we generally don't need to track glibc version. (This is a change in mindset for me, but I think it's correct). Futhermore, Apple does not typically change linked library versions on minor updates, so we could probably just track the major version for OSX (i.e. darwin-9 vs. darwin-9.4 or darwin-9.4.0). So here's a proposal. Let's track the processor architecture, operating system name and major version if it's available. This would yield identifier strings like: i386-linux i386-freebsd6 powerpc-darwin8 powerpc-darwin9 x86_64-linux For FreeBSD and Darwin, that should work fine. Linux should work as well, 90% of the time -- there may be odd instances where a package could require a specific incantation of Kernel version and/or glibc and/or gcc -- but I don't think it's worth tracking all those variations -- people can always build their own repos if they want to get real specific about that sort of thing (indeed if you're using erlware in production, that would be my recommendation, simply from a QA standpoint). What this also means is that we should generate versions of our bootstrapper to this same convention, so that there are no questions about which version of faxien you need. Coincedentially, this will also fix a problem with the bootstrapper (and faxien) where there is an elaborate guessing game about the right bootstrapper to grab -- we can standardize the algorithm for generating a system architecture identifier and get everyone on the same page. Thoughts? D. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en -~----------~----~----~----~------~----~------~--~---
