Simple answer for this one: It should be configurable and an option in Compile.conf....let the power users upgrade as soon as its available....by default let users interpret it as minimum dependency so that the System does not break.
For end users, symlinking and broken links are not very good...we need to have the system acceptable to diverse levels of skill sets. Me personally, would like the latest and greatest everytime :) My 2 cents/paise/pence/<put your favorite currency here> Anshuman ----- Original Message ----- From: "Jonas Karlsson" <[EMAIL PROTECTED]> To: "Development of the GoboLinux distribution" <gobolinux-devel@lists.gobolinux.org> Date: Fri, 17 Aug 2007 21:03:32 +0200 Subject: Re: [gobolinux-devel] Handling of old dependencies format > On Thu, 16 Aug 2007 05:50:33 +0200, <[EMAIL PROTECTED]> wrote: > > > On 8/15/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > >> An old issue that I just encountered, is that depencencies in the old > format > >> "Foo x.y" is interpreted as just "Foo" while it really should be > interpreted > >> as "Foo >= x.y" imo. In my case it was the GnuPG recipe that listed > >> "LibAssuan 1.0.2", while I had 1.0.0, which made configure die when it > >> didn't find a version of that library that matched the prerequisite. We > >> still have some hundred recipes in the store, which have the old > dependency > >> format and I cannot guess how many of those that are broken because of > not > >> using the version given as a lower limit. > > > > This has been discussed in the past (offlist, perhaps) and André > > decided for the current behavior. IIRC his rationale was that the ">=" > > behavior would force too many unnecessary upgrades as the recipe > > writer is usually beyond the lower bound of the recipe. > > This exact discussion was most probably offlist. I really see the problem > with > using ">=". Most of all, I don't see the difference between interpreting old > recipes versions as lower bound and a user using BuildInformation and just > copy-pasting "Foo x.y", only adding a ">=" (this is probably how "normal" > users > create their Dependencies file, and maybe they don't add the ">=" part). For > the users using the recipe there's still a choice in installing the > dependency. > > > And every > > upgrade is an additional chance for something to break, so we went the > > conservative path there. If the new app you're installing fails to > > build, that's a lesser problem than breaking something that was > > working before because of a dependency (I know, in an ideal world > > recipes would be perfect and things wouldn't break, but you know what > > I mean). > > Are the chance on breakage, when compiling from source, that big?! We're > talking about compiling here, not installing a binary package. > > > I prefer keeping the current behavior and fixing recipes that > > prove themselves buggy, like GnuPG. > > > I'd rather go the other way and risk breaking a system or two. The risk is > really, really small and a GoboLinux system is never that broken - just > remove > some symlinks and add some other and your good to go again. Rather that than > having Compilation die on me ever so often. Not that it happens that often, > I > have had it happen to me twice this year (not counting all the times it > happened > while I was trying to update a recipe), but so far I have never broken my > system due to answering yes to upgrade (apart from upgrading glibc, but > that's > another, old issue). > > This far we've only heard mine and André's view on this. Doesn't anyone > else has > an opinion in this? > > -- > /Jonas > > PS. Reading back I found a note about "--mode=syntax" for CheckDependencies > - I > still want it. > > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > gobolinux-devel mailing list > gobolinux-devel@lists.gobolinux.org > http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel >
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
