and die when it detects one of course. Jakub posted a list of those deprecated eclasses here: http://rafb.net/paste/results/nkpesC59.html Additionally kernel-mod.eclass should be in the list. I think the list should be put in /usr/portage/eclass/deprecated but the portage people have to decide about this. Can we please implement this? :)
Better post it here, pastebins suck ;) 64-bit, darcs, db4-fix, debian, embassy-2.10, embassy-2.9, gcc, gnustep-old, gtk-engines, gtk-engines2, inherit, jakarta-commons, java-pkg, java-utils, kde-base, kde-i18n, kde-source, kmod, koffice-i18n, motif, mozilla, myth, pax-utils, perl-post, php, php-2, php-ext, php-ext-base, php-ext-pecl, php-ext-source, php-lib, php-pear, php-sapi, php5-sapi, php5-sapi-r1, php5-sapi-r2, php5-sapi-r3, tla, webapp-apache, xfree
We should store the list of deprecated eclasses in the portage tree somewhere so that we don't have to hard code them in repoman. How about $PORTDIR/metadata/eclass.deprecated? Should this check result in a warning or be fatal?
(In reply to comment #2) > We should store the list of deprecated eclasses in the portage tree somewhere > so that we don't have to hard code them in repoman. How about > $PORTDIR/metadata/eclass.deprecated? Should this check result in a warning or > be fatal? > Fatal, as long as the upgrade path is provided. In this case comments should be required in the eclass.deprecated file, such that in the event of a repoman fatal error repoman can print the comment (similar to package.mask). something like: repoman scan eclass.deprecated - foo.ebuild attempted to use really-old.eclass, please fix the ebuild to work with shiny-new.eclass eclass.deprecated: really-old.eclass shiny-new.eclass
Do not put it into $PORTDIR/metadata. How about a new dir for repoman data, I don't think this will the only file we'll ever need for repoman (in fact we already have another one, metadata.dtd), so a separate location makes sense (allow users to exclude them on sync).
Perhaps $PORTDIR/eclass/deprecated would be a logical location? After thinking a bit, I want it directly in $PORTDIR/metadata either. We could make a subdirectory for QA metadata. Perhaps $PORTDIR/metadata/qa/eclass.deprecated?
Marius has helped convince me that metadata/ should be reserved for files that are pulled in from places other than gentoo-x86 specifically for convenient distribution via the rsync tree. If we add a metadata/ directory to gentoo-86 itself and overlay it with the existing stuff then it would be needlessly messy. So, how about $PORTDIR/qa-data/eclass.deprecated then? We should announce this on the -dev list since all the devs will need to know about this file.
(In reply to comment #3) > Fatal, as long as the upgrade path is provided. > > In this case comments should be required in the eclass.deprecated file, such > that in the event of a repoman fatal error repoman can print the comment > (similar to package.mask). Why clutter the file with with comments that basically say "never use this eclass and use something else instead"? Can't they just put some kind of comment in the old eclass itself about why the eclass is deprecated and a suggested migration path? Eclass deprecation shouldn't be a reversible process like package masking is, so comments in the deprecation file don't seem nearly as useful.
> Fatal, as long as the upgrade path is provided. From an arch tester point of view, this is very annoying. It would likely result in arch devs being unable to stablize newer ebuilds which are fixed because old ones still inherit the deprecated eclasses, like in the case of modular X. But if it doesn't fail, people problably won't fix it, so... *shrug*
(In reply to comment #8) > > Fatal, as long as the upgrade path is provided. > > From an arch tester point of view, this is very annoying. It would likely > result in arch devs being unable to stablize newer ebuilds which are fixed > because old ones still inherit the deprecated eclasses, like in the case of > modular X. But if it doesn't fail, people problably won't fix it, so... *shrug* > It's moreso for me a class of "what is fatal and what is not" Ebuilds that will fail due to invalid spacing, or just brokenness are fatal, ebuilds missing key variables are fatal, ebuilds inheriting eclasses that are broken/deprecated, are fatal. Ebuilds missing modular X deps, not so fatal. I think a fatal error is good, as long as everyone understands that ebuilds should be migrated prior to marking an eclass as deprecated. Aka you grep the tree for violators and file bugs, once those bugs are closed, file again, find 0 ebuilds, deprecate. Not, Oh I want this eclass deprecated, so deprecate it and then screw over everyone trying to do actual work. The intent for this check is to prevent new devs and new ebuilds from inheriting eclasses that "look ok" but may in fact be old/deprecated.
(In reply to comment #9) > Aka you grep the tree for violators and file bugs, once those bugs are closed, > file again, find 0 ebuilds, deprecate. Given that fact, I'm all for making it fatal.
Well, we could do both. How about eclass.deprecated and eclass.obsolete?
(In reply to comment #11) > Well, we could do both. How about eclass.deprecated and eclass.obsolete? I'd rather not, gets too confusing IMHO.
(In reply to comment #12) > I'd rather not, gets too confusing IMHO. Fair enough. I guess the scripts (other than repoman) that people use to scan for such things will fill the gap until we're ready to fully deprecate an eclass. If we're all satisfied with $PORTDIR/qa-data/eclass.deprecated then it's about time that we announce it on -dev and get the file added to the repo.
obviously no one is interested there ..
i am
Dunno, but we should agree upon a way of deprecating eclasses first -> sending to PMS folks. ;)
Not sure what PMS should say about this. Eclass removal policy has been addressed by the council, see bug 341959. Closing.
