So, here's a intermediate reply -- I'm still a little stuck on how to proceed in detail, but here are ramblings/thoughts I've had on it...
> 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. Great -- but why is Linux different? As an aside, we'll probably wind up having to parse the uname string in a platform dependent way to get the info we want out... > 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. ...snip > 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. After making my proposal I'm still a little hung up on what we should do about glibc. The root of the issue is that there is no "standard" Linux distribution and the release schedule of glibc can be sporadic/random. We can't really use glibc as a designator because of the (apparent) random distribution of glibc versions across Linux -- but if we leave it out, we risk people deploying libraries to the public repos that cause segfaults due to a glibc mismatch -- that's _very_ bad. And now for a little rambling thought... We have an orthogonal (or seemingly so) issue right now when it comes to dealing with erts upgrades. The way the repos are setup, we'll have to find some way to automatically "upgrade" code across erts versions -- i.e. if I publish a "generic" package for erts 5.5.5, I really, really don't want to have to manually republish for 5.5.6. Couple this issue with the glibc versioning problem and I have to wonder if we have a fundamental design problem. There are M erts versions for N platforms, and both M and N are growing more quickly than we can handle. I'm sure this isn't going to be a popular suggestion, but here it is... I think we _need_ to get rid of ERTS/platform specific packages and make faxien work more like CPAN (or ports, gentoo, etc.), where the source is downloaded and compiled on demand. When someone wants to install an application package, this enables us to compile using the erts version they have selected, for their platform, all without requiring the repo maintainer to have pre-existing knowledge about their specific config. We can then bring some sanity to the process of releasing faxien on Linux, since we have some control over the version of glibc used for faxien and can specifically establish a lower bound of glibc that we support. It also drastically simplifies repo management since we don't have to republish the _entire_ repo every release of Erlang. Of course, solving big problems is never cheap -- we'd have to rework a lot of stuff. Faxien would need to have stuff added into it that would support the building of packages -- and we'd have to work out a way to enable users to construct bash scripts that could be invoked as part of the build (for "binary" packages). I'm not sure where this would leave Sinan, since it seems like Sinan is designed for something different (i.e. long running/continuous builds). All of those challenges aside, I do think it would improve the long term viability of erlware as a whole, since it would be easier to manage and cheaper for people to publish into (since they don't need to constantly re-publish). Of note, even if we decide not to go this route, we'll still wind up with a variant of it if we want to do "auto" erts transitions/upgrades of packages. </rambling> Still pondering, but that's what's been going through my head the past 5 days... :) 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 -~----------~----~----~----~------~----~------~--~---
