Great email. Agreed, this is something we should sort out sooner rather than later. More commentary below and inline.
On Fri, Aug 29, 2008 at 11:45 PM, Dave Smith <[EMAIL PROTECTED]> wrote: > > 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? Currently this is fixed for all OS types but linux. The get system info function in ewr_util now uses uname to pull the kernel version from the actual OS as opposed to from erlang:system_info/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). Yes, this definitely is a problem. Nowdays we should not see it with mac but certainly with linux, which by the way is our biggest user community. > > > 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). This is definitely correct - GLIBC is backward compatible, but not forwards. So 2.3 will work just fine on 2.7 but not the other way around. > > > 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 The problem I see is when i386 linux means glibc 2.7 and I am running a machine with 2.3. In that case we have an issue. > > > 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 -- I completely agree - 90% or 95%, 99% even will work just fine. > 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. We need to move in this direction and I think we need to do it in a period of weeks not months. > > > 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 -~----------~----~----~----~------~----~------~--~---
