On Tue, Sep 2, 2008 at 11:12 PM, Dave Smith <[EMAIL PROTECTED]> wrote:
> > 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... The reason Linux is different is because there are many distributions and the version of the linux kernel and the version of glibc vary independently :( > > > > 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. Well, the 5.5.5 code having to move to 5.5.6 is not really an issue. Backward compatibility is maintained across patch versions. If you are running the latest Faxien you will see that when installing a release it prints out the version of Erlang that each app it installs was compiled for. Try installing Sinan and notice that the first app, I think it is the sinan_web_api, was compiled for R12B-3 while most other apps were compiled for R12B-3. There are a few other too. Faxien will basically pull down apps from lower patch versions if it can't find an exact match. This poses no problem and it makes our issue more simple. For all other OS's the the version of the OS and glibc progress together. Mac will not be releasing 10.5.x with glibc 2.7 and then 11.0.0 with glibc 2.3 for example - same for BSDs and so on. Linux is the only single kernel multi distribution OS I know of, or at least the only we will be supporting. I think we can handle it as a special case. I think the above sufficiently reduces the variables enough for us to consider a scheme to allow for more elegance and uniformity in handling versions. What do you think? Also, I am not opposed to a fork of Faxien that does exactly what you indicate below. I think it should be an experiment, in BETA, and we can see how it works. The problem of package management is non trivial and the development of a new system should not be a big bang which leave the community without a package manager for too long. The community needs package management now and I don't think we can wait too long to deliver it in 1.0 form. If the build locally method proves tractable and easier then we can switch over. Cheers, Martin > > > 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 -~----------~----~----~----~------~----~------~--~---
