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 1Hwuld-0004eW-Di for garchives@archives.gentoo.org; Sat, 09 Jun 2007 06:49:46 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l596mVT0032511; Sat, 9 Jun 2007 06:48:31 GMT Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l596iNR6027838 for ; Sat, 9 Jun 2007 06:44:24 GMT Received: by py-out-1112.google.com with SMTP id p76so2016824pyb for ; Fri, 08 Jun 2007 23:44:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UZfpBqL0FuBT2CUFSQjmLs+RYF7SvHh/CIdDyprpBPwZ/QvRJg4oALyX23TwAfsL4YLfXBAOgyY5eZcoDFAK4RM+kL/s/iv6e8HCV+JVr8R7pwbEWB0QR/YdLSnT9IbvceH5XJdYjK4xEK9mgA2RZ/4AnjCQMvPfcgnJgqDQwxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IEUfA9goXfpSe90PZ0lHW1iDJVEacu70JdSXZLEsPr/tytV/ZX9YBolFPlWNhXc6ePueI4lor3t4I5CTKyvrL4oeH2KmQRSZhZdyxvtpMtlnlw4bE+VP9BidLirauIwFoRrMgmnFsZizvQcdSYxM3RQPAS0BCeSH2dS1fC8iWxw= Received: by 10.65.163.8 with SMTP id q8mr6394685qbo.1181371463283; Fri, 08 Jun 2007 23:44:23 -0700 (PDT) Received: by 10.64.251.19 with HTTP; Fri, 8 Jun 2007 23:44:23 -0700 (PDT) Message-ID: <8cd1ed20706082344k4a9ca46br53c0b0f2022440ca@mail.gmail.com> Date: Sat, 9 Jun 2007 18:44:23 +1200 From: "Kent Fredric" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf? In-Reply-To: <20070608183725.GA20910@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: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070606234438.GE2575@nibiru.local> <200706071754.53896.bo.andresen@zlin.dk> <20070608124654.GA765@nibiru.local> <8cd1ed20706080618o4db2b1a8o1d59aac77898cdd3@mail.gmail.com> <20070608142020.GE765@nibiru.local> <8cd1ed20706080751vc827e34h5c828053d3991ce@mail.gmail.com> <20070608183725.GA20910@nibiru.local> X-Archives-Salt: 308a0c48-b13c-4a03-a93d-9affe03ac0e5 X-Archives-Hash: 7995f7d73acf0e180000df9d49b420c9 On 6/9/07, Enrico Weigelt wrote: > * Kent Fredric wrote: > > > Ah, but you see, in half the cases there is not a /complete/ > > incompatibility. PHP4<->5 migration is not an entirely big switch, > > the biggest problem IIRC in the 4->5 change is the way it handles > > classes, and a lot of code 'simply works' on both. > > I had to do a lot at that front. Believe me, they're NOT compatible. > Just nearly compatible. So different. > For those packages where it really doesnt matter, we simply could > use an virtual. > > Sama for java. So, your suggesting the following would have been a better option in this case dev-lang/php4/php4-4.4.3.ebuild dev-lang/php4/php4-4.4.4.ebuild dev-lang/php5/php5-5.1.1.ebuild dev-lang/php5/php5-5.2.0.ebuild virtual/php/php-5.ebuild -> dev-lang/php5/php5-5.2.0.ebuild virtual/php/php-4.ebuild -> dev-lang/php4/php4-4.4.4.ebuild ... and ... to have .. slotted virtuals like jdk does =P (this does give the added benefit that if somebody else were to create a PHP engine they could just jump into the virtual, or if one day php5 were to be /fully/ backwards compatible with php4 its version could be dumped into the php4 virtual and allow people to upgrade .. ) So either way you look at it, its just a case of /where/ the slotting occurs, not whether or not it occurs. > > > > > In the case of autoconf, im personally glad it all hides under one > > non-linear space-time-continumum on my harddrive ;) . The thought of > > them all being in seperate ebuild names would drive me nutty ( folder > > with 10 different package names for the same thing = wtf? ) > > What "folders" are you tallking about ? sys-devel/automake/automake-1.10.ebuild sys-devel/automake/automake-1.4_p6.ebuild sys-devel/automake/automake-1.5.ebuild sys-devel/automake/automake-1.6.3.ebuild sys-devel/automake/automake-1.7.9-r1.ebuild sys-devel/automake/automake-1.8.5-r3.ebuild sys-devel/automake/automake-1.9.6-r2.ebuild as theres 1 slot here /per/ ebuild, it would cause a bit of namespace pollution were you to "upslot" them, ie: instead of just one nice sys-devel/automake , you would need to have sys-devel/automake-1.10/automake-1.10-1.10.ebuild sys-devel/automake-1.4/automake-1.4-1.4_p6.ebuild sys-devel/automake-1.5/automake-1.5-1.5.ebuild sys-devel/automake-1.6/automake-1.6-1.6.3.ebuild sys-devel/automake-1.7/automake-1.7-1.7.9-r1.ebuild sys-devel/automake-1.8/automake-1.8-1.8.5-r3.ebuild sys-devel/automake-1.9/automake-1.9-1.9.6-r2.ebuild Which IMO would produce horror stories you could tell to your children, especially if many other packages currently utilizing slotting were to go that way. > > > > The argument of 'cleaning' was a problem for a little while, but im > > glad the kernel uses slotting, for the reason I dont want to have a > > seperate ebuild for different kernels, i dont want old kernel sources > > to be taken away when the new one turns up, and when i want to get rid > > of old kernels, i want to be able to do a nice and simple emerge -C > > <=some-version to get rid of them when im done with them. > > Okay, that's good point where slots are really useful. > But I'm sure there could be other good solutions. > > > The same occurs in many of the web-applications, where multiple versions > > are handy, but multiple ebuild names would cause headaches. > > hmm, they're an special things, since we can have many instances > of the same application here. but I never had the need to have > multiple versions of one webapp (source) installed. The reason for this, I believe, is that webapps regularly need to be hand-adjusted to suit the users needs, and needs hand tuning for each upgrade. Often this automated upgrade can break stuff ( can, but if you've not changed from default, it usually runs fine ), so I guess the reason is similar to the kernels, "less stuff breaking" i guess. ( Although ATM, its unobvious how to switch between webapp slots :S ) > > the only way to get around all these nasties would be to have a 3 part > > package name imo, such as > > dev-libs/gtk/2/2.0.1.ebuild > > dev-libs/gtk/1/1.0.1.ebuild > > for instance , and when you look at it like that, it is in essence > > identical to 'slots', except a 'slot' is governed by a string in the > > actual file, instead of a string in the filename. > > Well, if the slot number would be an part of the package atom name, > it would be half as bad. I definately aggree, which would help many apps out in following problem slotting currently has : "It is not possible to DEPEND upon a package in a specific slot." [1] For some things, such as things which require automake, & friends, it would permit them to use some sort of syntax such as %=sys-devel/automake-1.9 %<=sys-devel/automake-1.9 %>=sys-devel/automake-1.9 Why that syntax ? Well , we have a dilemour, if we were to change the way package atoms were named, it would break /craploads/ of the stuff already available expecting the 'old way' how do we make this easy to use? Heres my proposition, and thats slot-files. Like virtuals, but on a per-package level. (Cos virtuals are really designed to handle multiple packages that provide the same function, not one package which produces multiple different functions ) sys-devel/automake/automake-1.9.slot <-- note the suffix. This file would contain none-other than a list of packages which comprise that slot. packages emerged without -1 would be injected into world as a 'user asked for this slot' ie: %sys-devel/automake-1.9 thus preventing the erronious cleaning of slots, and permitting packages to directly depend on a given slot. In essence, this does what we did with virtuals. Virtuals I believe, either used to be defined in some global text file, or as a string inside each packages ebuild, but my memorys a bit rusty as to exactly how it used to work. This suggestion, is a de-ebuilding of slotting control somewhat. Now these are just my suggestions to how we could fix your oppositon of the current slotting system, and perhaps improve gentoos slot function without breaking it for all existing things. Your thoughts & suggestions appreciated. *1 http://devmanual.gentoo.org/general-concepts/slotting/index.html -- Kent ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x| print "enNOSPicAMreil kdrtf@gma.com"[(2*x)..(2*x+1)]}' -- gentoo-user@gentoo.org mailing list