From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1Hwe0M-00056x-RV for garchives@archives.gentoo.org; Fri, 08 Jun 2007 12:55:51 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l58CrtHF020790; Fri, 8 Jun 2007 12:53:55 GMT Received: from s15216962.onlinehome-server.info (s15216962.onlinehome-server.info [217.160.22.205]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l58ClXE4011825 for ; Fri, 8 Jun 2007 12:47:37 GMT Received: (from uucp@localhost) by s15216962.onlinehome-server.info (8.13.3/8.13.3/SuSE Linux 0.7) with UUCP id l58Cl3Ep032004 for gentoo-user@lists.gentoo.org; Fri, 8 Jun 2007 14:47:03 +0200 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id l58Cks9g011987 for gentoo-user@lists.gentoo.org; Fri, 8 Jun 2007 14:46:54 +0200 Date: Fri, 8 Jun 2007 14:46:54 +0200 From: Enrico Weigelt To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf? Message-ID: <20070608124654.GA765@nibiru.local> References: <20070606234438.GE2575@nibiru.local> <200706071754.53896.bo.andresen@zlin.dk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200706071754.53896.bo.andresen@zlin.dk> User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof X-Archives-Salt: 16c9a0c4-c7b8-4061-aca9-adb92c4dc489 X-Archives-Hash: cc96bc423c4f3b657fb78be4e982875b * Bo =D8rsted Andresen wrote: Hi, > > These are packages totally incompatible and so different > > packages under the same name. They're sometimes necessary, > > since certain projects still require very old version, > > even if upgrade wouldn't be such a problem and has already > > been done by contributors (ie. mozilla). >=20 > Well, they still are different versions under the same packages=20 > from the same projects. Evolutionarily yes, technically no ;-P They're in fact very diffrent, but provide an very similar (almost the same) functionality. The problem is: upstream claims that newer evolutions steps=20 were newer versions, Gentoo takes it as it is and runs into=20 trouble, the attempt to fix this is slotting.=20 If we simply would consider them as different packages, the whole story would be trivial. We just have to decide at=20 which point a split has to be done. The whole complexity of slotting and the still unsolved problems (ie. cleaning up) could be dropped and dependency handling would be easy. For example gtk: First there was gtk-1.x. Later came gtk-2.x. They never were compatible (except maybe early alpha state ;-)). They always have been different packages, very similar, but different. So if gtk-2.x would simply be called gtk2, the whole idea of slotting wouldn't be necessary here. There are packages depending on gtk and others depending on gtk2. Trivial. Same with autoconf. The numbering is not that easy here, since major breaks sometimes happen with minor version changes. So we just have to look a bit more cafully. But still much simpler as adjusting all these versioned dependencies which are necessary with slotting. Maybe it would be different if the slot number would be essential part of the package atom. But I'm not sure if it's really necessary to have such an additional complexity if there is an clear scheme for putting those "evolution levels" into the package name. Gentoo always tries to stay as near as possible to the upstream. Thats okay, if we're talking about patches. But taking those crappy versionings from the upstream IMHO produces unnecessary trouble > > Gentoo has an strange magic for handling that, called "Slots". > > They deeply break the linear version space. This makes handling > > very tricky and requires much additional complexity. Some of > > the other replies should make clear some prolems ... >=20 > I have no idea what breaking 'the linear version space' means.=20 Let's try some little (some bit mathematic) definition: =20 Version numbers are living within an scalar 1-dimensional space,=20 ie. like rational numbers, but with holes. (ups, it's not really=20 linear if we have holes ;-o). But all numbers are comparable with=20 <,>,=3D operations. We normally represent them as n-vectors, ie. in=20 form of 1.2.3.4 but in fact the right side dimensions are intervals in the left side ones. Assuming the digits may take 0..9, we could=20 define the scalar value of A.B.C.D as A*1000+B*100+C*10+D ... (My Briegel buildsystem, which is a little bit like portage, but for=20 embedded/crosscompiling, uses this model as well as the Comprehensive Source Database ;P) The Idea of this "linear" version space is that we can compare each version with another one very easy. Additionally use the axiom that higher versions are always successors of lower ones and backwards compatible. In this situation the whole package management story is really easy. Things like slots are not necessary. If we also take in binary compatibility, revdev-rebuild is also not needed. Evrything is strictly defined in the dependency graph. > And I don't see how having automake in 7 different packages instead=20 > of seven slots under the same package makes it any less complex. It WILL make it easier. The whole slot handling could be dropped off (makes the code much easier) and the problems with slots simply=20 would not exist.=20 =20 > How is having a depend on =3Dsys-devel/automake-1.4* or sys-devel/automak= e:1.4=20 > any more complex than a depend on a separate packages named=20 > sys-devel/automake-1.4 ?=20 What if now comes an 1.4.99 which is totally incompatible with the other 1.4.* ? What do you do now ?=20 Drop that 1.4.99 ?=20 Give it another version, ie. some 1.5.* ? Touch all depending patches to exclude 1.4.99 ?=20 > There are actuallly packages in the tree that don't care which version=20 > of automake is in use (at least according to there ebuilds). Now they=20 > just depend on sys-devel/automake. With your brilliant solution they=20 > would have to depend on || ( sys-devel/automake-1.4=20 > sys-devel/automake-1.5 ... ). Simply add an virtual for that ?=20 BTW: (beside rare cases), ebuilds normally sould have no variants in their dependencies - this should be left to the virtuals, IMHO. > > No idea, why the responsible Gentoo-devs didn't just give > > those incompatible packages different names, especially on > > their own packages. AFAIK, java-config is made by Gentoo. > > It would be trivial, just to call the 2.x version something > > like java-config-2 ... perhaps too simple for them ? >=20 > It still doesn't change the problem that if they have different=20 > files with the same name they need to install it in different=20 > places. That problem is just the same whether in slots or separate=20 > packages. Right. But that argument is neither for slots nor against.=20 > [SNIP] > > As someone else already that: one of the problems with slots. > > They don't work well on cleanup. I wonder if anybody ever thought > > about that when slots were introduced. >=20 > --depclean does actually remove unneeded slots now for packages=20 > not in system or world. Well, I didn't prove it by myself - just took the input from this=20 list, where people stated it would NOT do it cleanly. > By removing slotting you take away flexibility and make things=20 > in a source distribution harder. What flexibility do I take away exactly ? And what exactly gets harder ?=20 cu --=20 --------------------------------------------------------------------- Enrico Weigelt =3D=3D metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- gentoo-user@gentoo.org mailing list