Duncan wrote: > Joe Peterson wrote: >> In general, it makes sense to me to have an unversioned one if there is >> no version dependency - i.e. if xfce.eclass would likely work for future >> ones (like "xfce5"). I'm not sure why, other than to emphasize that a >> new version is out, upstream packages (like gnome, kde, etc.) include >> the version in the name. I actually just think of kde as "kde", myself, >> even if it happens to be version 4. ;) > > FWIW, KDE changes major versions seldom enough and with enough > differences between versions, that it's a good time to break package > handling and get rid of the cruft at the Gentoo level as well.
That's a valid reason, although eclass versioning (which someone, can't mem who, not a portage dev, told me was round the corner) would solve it more cleanly across the tree and allow the simplest name. The attraction of staying with one name is that the eclass can transition ebuilds and then lose the cruft once the packages are out of tree. Given that eclasses can test and change according to EAPI, what we have now would seem sufficient unless there is a major build system change, like KDE4 switching to cmake. > Presuming something similar for xfce, if xfce4 is taken but xfce isn't, > that would work, or perhaps xfce4ng.eclass... *ng is always good for a > round... and if it comes to it beyond that, g3, g4, etc. Of course, > that's sort of like Gentoo's -rX numbers for ebuilds, but the -rX concept > doesn't so well lend itself to the eclass concept as it implies a rather > faster turnover than we'd /hope/ to be the case, but -ng/-gX, that works. > =:^) > I like that naming schema but think it might be overkill here. Might be a more flexible way to do epochs, but I'm not sure we'd need more than one comparable value, and I think sticking to one int is sufficient.
