Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
* Kent Fredric [EMAIL PROTECTED] wrote: Hi, 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 Yes. 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 No. Not slotted ! Maybe some virtual for dependencies on an subset of php which works with both variants. Packages which are proven to run on both variants can use this virtual, just to get the || dep out there. 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 Ah, you're talking about the per-package subdirs. What's bad w/ having a few more of them ? as theres 1 slot here /per/ ebuild, it would cause a bit of namespace pollution were you to upslot them, ie: Is this really such a problem ? Maybe we could add another step in the hierachy, ie. called variant or evolution or whatever ... 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 Maybe it looks nice for you, but this looks like these were (exchangable) versions. Obviously they're NOT. These evolution steps are NOT compatible, neither upwards, nor backwards. It's really a luck if some packages work with more than exactly one automake version. The problem is that packages depending on those slotted ones have to depend on specific version numbers. Maybe its not that bad if the interface breaks only happen between major releases (so you can say things like =automake-1.7*), but it gets really tricky with breaks between minor versions. Some time ago I already had such situations w/ the autotools stuff. 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 ) Yes, webapps are still an story of their own. I don't see an better solution than the current webapp-config approach for now. But I don't think slotting is really necessary here. 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] Yep. If would make things much, much easier. It would IMHO also solve your concerns about namespace pollution, etc. In fact different slots then would be different (sub-)packages. 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 What shall that mean ? Use some specific range within some slot ? I could imagine some syntax like: sys-devel/automake/1_9 or sys-devel/automake+1_9 of sys-devel/automake%1_9 1_9 then is the slot/branch/subpackage name. You probably reconize the missing =. That'd be correct, since the slot is not part of the version, but the package name. 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' The new syntax should be an extension of the old one. An missing slot name just means choose best matchting slot. 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
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
* Bo Ørsted Andresen [EMAIL PROTECTED] wrote: Hi, Wtf. Newer versions are newer versions. No matter if they are fully backwards compatible or not. I really don't aggree your really loose view of versions. That's like seeing ISDN as an newer version of POTS. Well, if you're convinced about that, feel free to pull in an POTS phone on an UK0 line and see what happens ;-P (at your own risk!) The point is from the package manager point of view it would be trivial *because* the developers would have to do more of the work manually. Which manual work do you exactly mean, ie. if you simply treat gtk-1.x vs. -2.x as separate packages ? I.e. the work of creating new packages, removing old ones and creating/updating virtuals where they currently just do version bumps and remove old ebuilds. Is this really that much more than maintaining *version* dependencies on every single package which depends on slot'ed packages ? For example gtk: it would add only one more package, but make all version deps onto it, in every gtk using package, obsolete. I also *really* don't see how adding a dep on =automake-1.4* or automake:1.4 is harder or more complex than automake1.4 (which currently would be an invalid package name anyway). Well, what do you do if, ie. -1.9.3 would be incompatible to -1.9.2 ? I already had such cases with autotools stuff some time ago. Ah, and the whole extra complexity (in portage and ebuilds as well as for the admin) in having to cope with multiple versions means nothing to you ? The reason why cleaning cannot be done properly for packages in system or world is that the packages files that define the system set in the profiles and the world file don't support specifying slots. Right. If at least slot would be (optional) parts package names, this would be much easier. [SNIP] 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 nor ranged deps (with the exception of the not too powerful =foo* syntax). So please tell me how you could handle such an case. 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 breakage but even on ABI breakage (otherwise revdep-rebuild would still be needed)? At least on API break. If we also do it on ABI, we would have more breaks, but compatibility would be ensured just by the dependencies. Most of my jobs are building and maintaining firmware for embedded systems. Here MUST ensure binary compatibility on upgrades. There is nothing like revdep-rebuild, even no compiler on the target system. So you maybe can understand my constraints why I'm often very quick in declaring things broken :) 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 the virtual? Yes, of course. But what's with the packages depending on it ? See: Drop that 1.4.99 ? Give it another version, ie. some 1.5.* ? Touch all depending patches to exclude 1.4.99 ? Huh? Your answer's still missing. How to you handle that ? 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 same time. Would be simply not necessary if these incompatible packages were treaded as separate ones. ;-P In fact, slotting (IMHO) does not allow real MVCC. This would require *each* version its own slot and every version installed somewhere else. But MVCC is an topic for its own ;O What is now a simple version bump (that happens to use a new slot) or cleaning of obsolete versions becomes packages additions and removals plus updates to virtuals. Ok, then we maybe have to touch one or two more files (for the virtual). But the good side is that we don't necessarily do it in one step. And we're not limited to one virtual. For example php: we've got an virtual/php-v4, which represents the v4 style runtime system (or at least an subset of it). Certain versions of php5 match in here, so they can be added to the virtual. But we cannot be sure that all future versions will still fit in here. We need to decide it for each single version.
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On 6/13/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
Okay, this isn't really about slots vs. no slots, but shows that
slots are not necessary.
cu
Well, IMO everything should be slotted 100% every version able to be
installed in parallel, and packages depend on version, and versions
with no depends are obviously not needed and cleaned out ,,, but we'll
have to agree to dissagree ;)
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print enNOSPicAMreil [EMAIL PROTECTED][(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote: * Kent Fredric [EMAIL PROTECTED] 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. snip 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. snip 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
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
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 backwards 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 *because* the developers would have to do more of the work manually. I.e. the work of creating new packages, removing old ones and creating/updating 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 packages in seven dirs plus adding a virtual that's provided by all seven of those versions is easier than just having seven versions in the same package with different slots. I also *really* don't see how adding a dep on =automake-1.4* or automake:1.4 is harder or more complex than automake1.4 (which currently would be an invalid package name anyway). The reason why cleaning cannot be done properly for packages in system or world is that the packages files that define the system set in the profiles and the world file don't support specifying slots. At this point it would be pretty trivial to add both, however, the problem with that is backwards compatibility with older versions of portage itself. Profiles aren't versioned like ebuilds with an EAPI so there are no means to assure that people upgrade portage before getting profiles that are incompatible with older versions of portage.. Even today we still occasionally get bug reports from people who --sync with portage-2.0.51 which aren't compatible with the current profiles (bug #114798)... [SNIP] 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 nor ranged deps (with the exception of the not too powerful =foo* 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 breakage but even on ABI breakage (otherwise revdep-rebuild would still be needed)? Do you *any* idea how many packages that would result in? It would be a maintenance nightmare. Keep in mind that CVS doesn't even support removing a package properly (with it's dirs). [SNIP] How is having a depend on =sys-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 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
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On Saturday 09 June 2007 08:44:23 Kent Fredric wrote: %=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' That's what EAPI bumps are meant to solve. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
* Bo Ørsted Andresen [EMAIL PROTECTED] 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). 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. 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. 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 ... I have no idea what breaking 'the linear version space' means. Let's try some little (some bit mathematic) definition: Version numbers are living within an scalar 1-dimensional space, ie. like rational numbers, but with holes. (ups, it's not really linear if we have holes ;-o). But all numbers are comparable with ,,= operations. We normally represent them as n-vectors, ie. in 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 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 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 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 would not exist. How is having a depend on =sys-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 ? Drop that 1.4.99 ? Give it another version, ie. some 1.5.* ? Touch all depending patches to exclude 1.4.99 ? There are actuallly packages in the tree that don't care which version of automake is in use (at least according to there ebuilds). Now they just depend on sys-devel/automake. With your brilliant solution they would have to depend on || ( sys-devel/automake-1.4 sys-devel/automake-1.5 ... ). Simply add an virtual for that ? 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
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
What flexibility do I take away exactly ?
And what exactly gets harder ?
Automated building of dependant packages
Gentoo has a collection of magic script that do make this nice for us.
ie ( last I looked anyway ) java-config and autoconf were not binarys,
but scripts which pointed to the correct binary given the right
environment variables.
This makes the building of other packages that were invented upstream
without predicting changes in autoconf easier to maintain, instead of
having to send out a new patch every time upstream releases a
non-compatible-with-new-autoconfs version /just/ to make it work, we
just set WANT_AUTOCONF=1.4 in the environment and the appropriate
autoconf gets run, which seeems a fairly reasonable thing to do. (
otherwise the concept we have today known as a version bump would be a
whole deal harder more often)
I remeber the days of Java1.4 - Java1.5 migration headaches before
they slotted it and created java-confing system to get around it, boy
did it take its sweet ass time getting there ( cos there were at least
100 apps which needed 1.4 instead of 1.5, and if you compiled one of
those with 1.5 instead of 1.4, which the ebuild never expected to have
happen, due to being authored before 1.5's release , ... the entire
heirachy would break, and you'd give up and simply remove _ALL_ of
java just to keep sane, but thats not gentoos fault exactly, blame a
multitude of upstream javaheads for that )
As for gtk2-0.1 vs gtk-2.0.1, the latter is clearly a more logical
version number.
gtk2.0.1 is invalid (no - to separate version from subversion ), and
on top of that
if it was called gtk2 instead of gtk-2, it would need a separate
folder, and a completely different set of configs,
it was bad enough when php4 php5 were different applications. Im so
glad they slotted that. Its just annoying still that due to the
massive magnitude of apps for php4/5 that they have to have a separate
_TOP_LEVEL_ dir for them all.
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print enNOSPicAMreil [EMAIL PROTECTED][(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote: * Kent Fredric [EMAIL PROTECTED] wrote: On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote: What flexibility do I take away exactly ? And what exactly gets harder ? Automated building of dependant packages More precisely ? AFAICS it would be much easier w/o slots. I already mentioned Briegel. Here I'm strictly doing as described. This works great. The only reason for using Gentoo is that it has much, much more manpower than me alone. For most common systems Gentoo is quite good, for embedded targets (where I've got relatively few packages) I'm using Briegel. Gentoo has a collection of magic script that do make this nice for us. Which ones for example ? / What exactly do they do ? Would that magic be necessary with my approach ? ie ( last I looked anyway ) java-config and autoconf were not binarys, but scripts which pointed to the correct binary given the right environment variables. This makes the building of other packages that were invented upstream without predicting changes in autoconf easier to maintain, instead of having to send out a new patch every time upstream releases a non-compatible-with-new-autoconfs version /just/ to make it work, we just set WANT_AUTOCONF=1.4 in the environment and the appropriate autoconf gets run, which seeems a fairly reasonable thing to do. ( otherwise the concept we have today known as a version bump would be a whole deal harder more often) Yeah. Wrapper scripts. I also have such things @ Briegel. Please explain why this is an reasonable argument in the question whether or whether not to do slotting ? I remeber the days of Java1.4 - Java1.5 migration headaches before they slotted it and created java-confing system to get around it, Would it make a difference if sun-java-1.5 would have got it's own package name (distinct from -1.4) ? AFAIK -1.4 and -1.5 are really incompatible, almost as much as gtk-1.x vs. gtk-2.x. So why not treating them as different packages ? As for gtk2-0.1 vs gtk-2.0.1, the latter is clearly a more logical version number. Why not gtk2-2.0.1 ? if it was called gtk2 instead of gtk-2, it would need a separate folder, and a completely different set of configs, Yes, of course - it's an different package. it was bad enough when php4 php5 were different applications. Why ? php4 and php5 are very incompatible, almost as much as it had been with php3. This already had been clear when php5 was at alpha. I never ever expected them to be the same package. Of course evrything would be much clearer if there was an big consensous on naming the scripts with *.php4 and *.php3 as it had been done in history w/ php3. But this really has nothing to do with slotting vs. separate packages. 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 currently develop in 5 and then serve on 4, and even that has minimal errors in translation, so its not all /that/ bad. Same with java 1.4- 1.5, in most cases, the code the 'user' would be running needs minimal fixes, its just the bigger packages that cause the problems. ( I cant say if i know this is the case with GTK tho .. never been much of my feild of expertiese ) So we have a scenario where we have a mingling of styles for diferent user targets, we have slotting to keep the builds happy with unique versions, but we still have a migration path for users. Maybe to you that seems illogical, but to me, its handy and convenient. 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? ) 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. The same occurs in many of the web-applications, where multiple versions are handy, but multiple ebuild names would cause headaches. 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. Maybe slots are over abused in some cases, but there are IMO many uses for them which I'm thankful for, and in some cases where I wish packages had slotting on them. Mysql for instance
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
* Kent Fredric [EMAIL PROTECTED] wrote: On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote: What flexibility do I take away exactly ? And what exactly gets harder ? Automated building of dependant packages More precisely ? AFAICS it would be much easier w/o slots. I already mentioned Briegel. Here I'm strictly doing as described. This works great. The only reason for using Gentoo is that it has much, much more manpower than me alone. For most common systems Gentoo is quite good, for embedded targets (where I've got relatively few packages) I'm using Briegel. Gentoo has a collection of magic script that do make this nice for us. Which ones for example ? / What exactly do they do ? Would that magic be necessary with my approach ? ie ( last I looked anyway ) java-config and autoconf were not binarys, but scripts which pointed to the correct binary given the right environment variables. This makes the building of other packages that were invented upstream without predicting changes in autoconf easier to maintain, instead of having to send out a new patch every time upstream releases a non-compatible-with-new-autoconfs version /just/ to make it work, we just set WANT_AUTOCONF=1.4 in the environment and the appropriate autoconf gets run, which seeems a fairly reasonable thing to do. ( otherwise the concept we have today known as a version bump would be a whole deal harder more often) Yeah. Wrapper scripts. I also have such things @ Briegel. Please explain why this is an reasonable argument in the question whether or whether not to do slotting ? I remeber the days of Java1.4 - Java1.5 migration headaches before they slotted it and created java-confing system to get around it, Would it make a difference if sun-java-1.5 would have got it's own package name (distinct from -1.4) ? AFAIK -1.4 and -1.5 are really incompatible, almost as much as gtk-1.x vs. gtk-2.x. So why not treating them as different packages ? As for gtk2-0.1 vs gtk-2.0.1, the latter is clearly a more logical version number. Why not gtk2-2.0.1 ? if it was called gtk2 instead of gtk-2, it would need a separate folder, and a completely different set of configs, Yes, of course - it's an different package. it was bad enough when php4 php5 were different applications. Why ? php4 and php5 are very incompatible, almost as much as it had been with php3. This already had been clear when php5 was at alpha. I never ever expected them to be the same package. Of course evrything would be much clearer if there was an big consensous on naming the scripts with *.php4 and *.php3 as it had been done in history w/ php3. But this really has nothing to do with slotting vs. separate packages. cu -- - Enrico Weigelt== 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/ - -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On 6/9/07, Kent Fredric [EMAIL PROTECTED] wrote:
On 6/9/07, Kent Fredric [EMAIL PROTECTED] wrote:
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? )
Just replying to myself here.
] sys-devel/automake
Available versions:
(1.4) 1.4_p6
(1.5) 1.5
(1.6) 1.6.3
(1.7) 1.7.9-r1
(1.8) 1.8.5-r3
(1.9) 1.9.6-r2
(1.10) 1.10
screw making a seperate package for each of those.
Screw being the poor bastard who parsed the package names from the
ebuild titles to make it work :S
Oh yeah, bags not doing linux-gazette or app-doc/phrack
Some of us have lives to get on with :P
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print enNOSPicAMreil [EMAIL PROTECTED][(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
* Kent Fredric [EMAIL PROTECTED] 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. snip 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 ? snip 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 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. cu -- - Enrico Weigelt== 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/ - -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On Thursday 07 June 2007 01:44:39 Enrico Weigelt wrote: Now... Why are there multiple versions of java-config, autoconf, and automake shown on my system? 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). Well, they still are different versions under the same packages from the same projects. 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. And I don't see how having automake in 7 different packages instead of seven slots under the same package makes it any less complex. How is having a depend on =sys-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 ? There are actuallly packages in the tree that don't care which version of automake is in use (at least according to there ebuilds). Now they just depend on sys-devel/automake. With your brilliant solution they would have to depend on || ( sys-devel/automake-1.4 sys-devel/automake-1.5 ... ). 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. [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. --depclean does actually remove unneeded slots now for packages not in system or world. By removing slotting you take away flexibility and make things in a source distribution harder. Not easier. Yes, it sucks that our current EAPI doesn't support that flexibility properly (by allowing slot deps) and that our current package manager doesn't support the flexibility that use deps would provide (hence dying in pkg_setup when a use flag was required). But the long term solution is not to remove the flexibility that these concepts provide but rather to support it properly in the package manager and EAPI. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) https://bugs.gentoo.org/show_bug.cgi?id=125728#c29 -- Bo Andresen Thanks, Bo -- editing the .la files fixes that problem. Now that the dependencies are fixed, I don't need to rebuild anything, do I? I guess if this was a problem with any of the ebuilds I merged onto the system before I fixed the dependencies, emerge would have resulted in an error? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
HI... On 31/05/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: --prune makes no checks of what's still required. [SNIP] But doesn't --prune just remove all but the most recent installation of a given package? Yes. I knew there was a reason I followed a --prune up with a -DNuva world as well as a revdep-rebuild. ...Ric -- Ric de France Ph: +61412945554 (international) or 0412945554 (Australia) == Do you, uh... Gentoo? Gent-hooo!! == == http://www.gentoo.org/main/en/about.xml == -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On Wednesday 30 May 2007 21:23:00 Denis wrote: Why are there multiple versions of java-config, autoconf, and automake shown on my system? They are incompatible, slotted, and each slot is individually required (or was at some time). There could be other multi-version packages... Is this normal for portage that is configured to autoclean? Yes. Autoclean doesn't uninstall versions in a different slot. I'm not sure about depclean. If so, I find it rather interesting that packages would depend on so many different versions of automake, for instance! HA. autohell is that way because there's little backward or forward compatibility. (Well, that and m4.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/ pgpGlwvJ7LX05.pgp Description: PGP signature
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
Hi, On 31/05/07, Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: There could be other multi-version packages... Is this normal for portage that is configured to autoclean? Yes. Autoclean doesn't uninstall versions in a different slot. I'm not sure about depclean. I think what is more useful is --prune (I'm guessing as I'm not in front of a Gentoo box at the moment). I usually try: # emerge -Pp to see all the possible pruning that can be done. Then individually prune packages using: # emerge -P package name I'm sure there's a better way to do things. Also be sure to follow up a prune with a deep world emerge, ie.: # emerge -DNuva world It'll make sure if you prune something like automake that isn't back / forth - compatible will be restored to your system. HTH, Ric -- Ric de France Ph: +61412945554 (international) or 0412945554 (Australia) == Do you, uh... Gentoo? Gent-hooo!! == == http://www.gentoo.org/main/en/about.xml == -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On Thursday 31 May 2007 04:43:07 Boyd Stephen Smith Jr. wrote: There could be other multi-version packages... Is this normal for portage that is configured to autoclean? Yes. Autoclean doesn't uninstall versions in a different slot. I'm not sure about depclean. With the latest versions of portage --depclean does clean unneeded slots for packages not in system or world. Since system and world doesn't support specifying slots it can't do it for those though. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On 5/30/07, Ric de France [EMAIL PROTECTED] wrote: I think what is more useful is --prune (I'm guessing as I'm not in front of a Gentoo box at the moment). I usually try: # emerge -Pp Here's the output: myhost etc # emerge -Pp These are the packages that would be unmerged: dev-java/java-config selected: 2.0.32 protected: 1.3.7 omitted: none sys-devel/automake selected: 1.10 1.6.3 1.7.9-r1 protected: 1.9.6-r2 omitted: none sys-devel/autoconf selected: 2.61 protected: 2.13 omitted: none 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. But doesn't --prune just remove all but the most recent installation of a given package? While on the subject, I ran a pretend on revdep-rebuild, and it's complaining about some broken libraries in GCC... langevin etc # revdep-rebuild -p -v Configuring search environment for revdep-rebuild Environment mismatch from previous run, deleting temporary files... Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot -p -v =sys-devel/gcc-4.1.2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-4.1.2 USE=fortran gcj gtk mudflap nls (-altivec) -bootstrap -build -d -doc (-hardened) (-ip28) (-ip32r10k) (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. I'm a little uneasy doing a --oneshot emerge of GCC when I just recompiled my system twice... I'm not sure how that will affect my GCC upgrades in the future. I only upgraded a minor version of GCC, too. Any thoughts? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On Thursday 31 May 2007 05:53:08 Denis wrote: On 5/30/07, Ric de France [EMAIL PROTECTED] wrote: I think what is more useful is --prune (I'm guessing as I'm not in front of a Gentoo box at the moment). I usually try: --prune makes no checks of what's still required. [SNIP] But doesn't --prune just remove all but the most recent installation of a given package? Yes. While on the subject, I ran a pretend on revdep-rebuild, and it's complaining about some broken libraries in GCC... [SNIP] broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) https://bugs.gentoo.org/show_bug.cgi?id=125728#c29 -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
While on the subject, I ran a pretend on revdep-rebuild, and it's complaining about some broken libraries in GCC... [SNIP] broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) https://bugs.gentoo.org/show_bug.cgi?id=125728#c29 Oh fun! found me a bug... which is still open for over a year... It's funny how my other Gentoo box doesnt have any broken GCC libraries (although also upgraded to GCC 4.1.2) but instead has a broken GIMP library that needs libexif.so.10. So... edit the *.la files or create symlinks? ;-) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?
On Thursday 31 May 2007 06:25:58 Denis wrote: While on the subject, I ran a pretend on revdep-rebuild, and it's complaining about some broken libraries in GCC... [SNIP] broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) https://bugs.gentoo.org/show_bug.cgi?id=125728#c29 Oh fun! found me a bug... which is still open for over a year... It's funny how my other Gentoo box doesnt have any broken GCC libraries (although also upgraded to GCC 4.1.2) but instead has a broken GIMP library that needs libexif.so.10. Those two .la files only exist when the gcj use flag is enabled for gcc. So... edit the *.la files or create symlinks? ;-) Yes. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
