Bugzilla Bug 48719

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...