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 1Hwyam-00033V-IT for garchives@archives.gentoo.org; Sat, 09 Jun 2007 10:54:49 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l59AqBaG018700; Sat, 9 Jun 2007 10:52:11 GMT Received: from shuttle.zlin.dk (port78.ds1-abs.adsl.cybercity.dk [212.242.227.17]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l59Ak4Sf011433 for ; Sat, 9 Jun 2007 10:46:04 GMT Received: from BA.zlin.dk (unknown [10.0.0.3]) by shuttle.zlin.dk (Postfix) with ESMTP id 7B00630068 for ; Sat, 9 Jun 2007 12:46:04 +0200 (CEST) From: Bo =?iso-8859-1?q?=D8rsted_Andresen?= To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf? Date: Sat, 9 Jun 2007 12:46:04 +0200 User-Agent: KMail/1.9.7 References: <200706071754.53896.bo.andresen@zlin.dk> <20070608124654.GA765@nibiru.local> In-Reply-To: <20070608124654.GA765@nibiru.local> 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: multipart/signed; boundary="nextPart2627398.frDmPWYAhV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200706091246.04667.bo.andresen@zlin.dk> X-Archives-Salt: e960c55d-cf05-42bf-a809-29f9829d5ab1 X-Archives-Hash: b618b788af40149788b02b6b0ce10b8f --nextPart2627398.frDmPWYAhV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 08 June 2007 14:46:54 Enrico Weigelt wrote: > > Well, they still are different versions under the same packages > > 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 > were newer versions, Gentoo takes it as it is and runs into > trouble, the attempt to fix this is slotting. Wtf. Newer versions are newer versions. No matter if they are fully backwar= ds=20 compatible or not. > If we simply would consider them as different packages, > the whole story would be trivial. We just have to decide at > 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. The point is from the package manager point of view it would be trivial=20 *because* the developers would have to do more of the work manually. I.e. t= he=20 work of creating new packages, removing old ones and creating/updating=20 virtuals where they currently just do version bumps and remove old ebuilds. I *really* don't see how adding seven versions of automake as seven package= s=20 in seven dirs plus adding a virtual that's provided by all seven of those=20 versions is easier than just having seven versions in the same package with= =20 different slots. I also *really* don't see how adding a dep on =3Dautomake-= 1.4*=20 or automake:1.4 is harder or more complex than automake1.4 (which currently= =20 would be an invalid package name anyway). The reason why cleaning cannot be done properly for packages in system or=20 world is that the packages files that define the system set in the profiles= =20 and the world file don't support specifying slots. At this point it would b= e=20 pretty trivial to add both, however, the problem with that is backwards=20 compatibility with older versions of portage itself. Profiles aren't=20 versioned like ebuilds with an EAPI so there are no means to assure that=20 people upgrade portage before getting profiles that are incompatible with=20 older versions of portage.. Even today we still occasionally get bug report= s=20 from people who --sync with 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. [SNIP] Indeed the real problem is that the current EAPI supports neither slot deps= =20 nor ranged deps (with the exception of the not too powerful =3Dfoo* syntax). > > > 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 ... > > > > I have no idea what breaking 'the linear version space' means. [SNIP] > 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. Wow. You're actually suggesting making a new package not only on API breaka= ge=20 but even on ABI breakage (otherwise revdep-rebuild would still be needed)? = Do=20 you *any* idea how many packages that would result in? It would be a=20 maintenance nightmare. Keep in mind that CVS doesn't even support removing = a=20 package properly (with it's dirs). [SNIP] > > How is having a depend on =3Dsys-devel/automake-1.4* or > > sys-devel/automake:1.4 any more complex than a depend on a separate > > packages named > > sys-devel/automake-1.4 ? > > What if now comes an 1.4.99 which is totally incompatible with the > other 1.4.* ? What do you do now ? Add a 1.4.99 slot? Just like you'd create a new package for it and add that= to=20 the virtual? > Drop that 1.4.99 ? > Give it another version, ie. some 1.5.* ? > Touch all depending patches to exclude 1.4.99 ? Huh? [SNIP] > > > 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 ? > > > > It still doesn't change the problem that if they have different > > files with the same name they need to install it in different > > places. That problem is just the same whether in slots or separate > > packages. > > Right. But that argument is neither for slots nor against. So that still leaves me without a clue about what problem making=20 java-config-{1,2} different packages rather than slots would solve. [SNIP] > > --depclean does actually remove unneeded slots now for packages > > not in system or world. > > Well, I didn't prove it by myself - just took the input from this > list, where people stated it would NOT do it cleanly. The ability to do that has been added rather recently. > > By removing slotting you take away flexibility and make things > > in a source distribution harder. > > What flexibility do I take away exactly ? > And what exactly gets harder ? The ability to have more than one version of the same package installed at = the=20 same time. What is now a simple version bump (that happens to use a new slo= t)=20 or cleaning of obsolete versions becomes packages additions and removals pl= us=20 updates to virtuals. =2D-=20 Bo Andresen --nextPart2627398.frDmPWYAhV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQBGaoTs8/kKEzmwNNoRAi9cAJ9NG2m1p0jghdmT3YwkEWwt10HJFgCeNwm4 /OIj5XeamMXQbS/mj76EoRs= =BfTq -----END PGP SIGNATURE----- --nextPart2627398.frDmPWYAhV-- -- gentoo-user@gentoo.org mailing list