I've been using ion since it was just ion, now the stable release is ion2. The developers say ion3 is unstable (i.e. enough that most people won't want to use it) and ion3-svn is even more unstable. Right now, each version has its own category, but I have the feeling that portage offers a more graceful solution to this. What about putting all of them into an ion category (and perhaps an ion-devel/ category). The way I see it, ion3 is not for regular people, it's a developer's convenience tool in portage, so it might be reasonable to keep the development branch separate. However, I see no reason to keep ion and ion2 separate. ion(1) is no longer maintained, but it should be around in case someone wants to use it (like any older version). The way it is now is simply too confusing. I don't know if it's possible to simply put it all in one directory and mask the development ebuilds so that regular people will install the ion-2 ebuilds... any suggestions? To me (a guy who's never used masks or locks etc..), the simplest solution is to put developmental versions into ion-devel/ and stable or old versions in ion/ The developers in #ion are saying they like it the way it is, but in this scheme there will be too many ion folders in portage in the future (the cycle appears to be pretty fast). The main objection from Ngea there is this: ion3's config files are not compatible with ion2's (they changed the config format significantly). He thinks that when ion3 becomes stable and the ebuild moves into ion/, people will have problems because of that. I say, if the ion developers had decided it was worth while to make such incompatible changes, then they should have already considered the impact on users when they want to upgrade. Please, if anyone has some ideas on this, let me know. Reproducible: Always Steps to Reproduce: 1. 2. 3.
OK, I maintain ion* on Gentoo. Portage does have a SLOT mechanism for handling muliple versions of the same package. The reasons that I haven't used the SLOT mechanism here are: 1) The configuration files are so different between different ion versions that they are effectively different window managers. It is my opinion that many people do emerge -u world without checking the output and I do not wish to break these user's configurations. ion is very stable, ion2 is now very stable but went through many, many, changes during development which meant it was desirable to keep it separate. ion3, well, who knows what's going to happen? The config file format has changed again! 2) I can't work out a graceful way to handle a transition from ion's versions (which are dates) to something like ion-1.20020207, ion-2.20040407, ion-3.20040316, etc. The problem is that version number 2.20040407 is less than 20020207, i.e. ion version 1 under the old numbering scheme appears newer than version 2 under the new numbering scheme. There may be a way around this. 3) ion3 is for "official" releases of ion3, ion3-svn is a live ebuild that checks out the sources from ion's subversion repository and is designed for users who want to track ion3's development (like me). Portage's handling of live CVS/Subversion ebuilds isn't great because of versioning issues. This isn't necessarily a bad thing since we don't want too many live ebuilds in the tree :-) Anyway, if we can work out a sensible version scheme that: 1) puts different ion versions in SLOTs 2) is compatible with the exisiting version numbers 3) allows the svn live ebuild to work correctly then I'll happily implement it. As a side note, Debian is using the same system as Gentoo here. There has been some dicussion on the ion mailing list about this, but no-one's come up with a good solution yet. Cheers, Tom
I would just be disappointed if the trend kept going this way and we ended up with ion, ion2, ion3, ion4, ion5, ion-svn in portage all as separate packages. I think it's fair to assume the following: ion developers will use ion-svn, regular usuers will use ion2 or perhaps the less stable ion3 (the brave), nobody will use more than 1 version at a time? (why were you considering slots?) with that in mind, what is wrong with having: ion/ion-20010101.ebuild (really ion 1) ion/ion-20031012.ebuild (really ion 2) ion/ion-20040101.ebuild (really ion 3) (masked because of instability ~x86?) ion-svn/ion-svn Most people will really just want ion2, so the latest ion3 dated ebuilds would be masked ~x86, or in package.mask. In this scheme ion-svn and ion3 ebuilds would not be easily mistaken for stable packages. You could even mark some ion2 ebuilds as unstable in package.mask... The fact that ion devs totally changed the config formats is really just something users would have to deal with anyway, so warning could be given. Might it be possible to have an ion2 dated ebuild be blocked by ion1 dated ones? (blocking between different versions of the same application?). I suppose none of this will matter until we have too many ion packages though.. but it would be nice to make a transition sooner than later right?
this is old.. i suppose the old ions will just get removed as time goes on anyway.
No, the bug report is valid. I'm just being particularly slow at fixing it. Please leave open until fixed. Cheers, Tom
sorry bout that :)
For this to work, portage really needs to support upgrading within SLOTs, see bug # 4698. This is a long-requested feature...
