Gentoo Archives: gentoo-dev

From: "Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New eclass: autotools-utils.eclass
Date: Sun, 18 Jul 2010 01:55:33
In Reply to: Re: [gentoo-dev] New eclass: autotools-utils.eclass by Brian Harring
Hash: SHA1

On 18-07-2010 00:58, Brian Harring wrote:
> On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote: >> case ${EAPI:-0} in >> 2|3|4) ;; >> *) DEPEND="EAPI-TOO-OLD" ;; >> esac >> >> why not: >> >> case ${EAPI:-0} in >> 0|1) DEPEND="EAPI-TOO-OLD" ;; >> esac
Alexis, the problem with your alternative is that it's "too clever" and won't die/kill/stop the processing of the eclass for newer EAPIs that at any point in time no one can be sure will be compatible with the current eclass design. That's why it has been agreed that eclasses should specifically list all supported EAPI versions and die/kill/stop on all other EAPI versions.
> Do not go adding invalid DEPEND like that. Make the eclass die > instead.
Brian, this is being used in the tree already. IIRC, since the introduction of EAPI-2 in the tree, there were a few solutions present to the dev ml and the one agreed by people was the abuse of depend to have the PM fail on dependency resolution instead of calling die on an eclass - which iirc is / was forbidden by PMS. We can discuss the correctness of this use, but please take into account it's already being used so until we have such a discussion we can't "forbid" its use. grep EAPI-TOO-OLD $(portageq portdir)/eclass/* /home/gentoo-cvs/gentoo-x86/eclass/kde4-functions.eclass: *) DEPEND="EAPI-TOO-OLD" ;; /home/gentoo-cvs/gentoo-x86/eclass/poppler.eclass:has 2 ${EAPI} || DEPEND="EAPI-TOO-OLD" /home/gentoo-cvs/gentoo-x86/eclass/virtuoso.eclass: *) DEPEND='EAPI-TOO-OLD' ;;
> Seriously, and this is a general rant based on several years of > people adding stupid shit without considering the fallout: > > Whatever great new little trick you can think of for stuff like > this... it's wrong. Use the mechanisms that exist. If policy > forbids it, fix the policy, don't come up w/ "clever" hacks around > it. Fix the core issue instead. > > Wouldn't surprise me if portage would accept this and run with it, > blowing up at emerge time instead. Pkgcore and paludis however will > give you the finger *very* quickly since that's not a valid atom. > Don't piss on our parties w/ 'clever' tricks, do the right thing and > use a die. > > People will move their ass a helluva lot quicker when their ebuild > breaks than when bones has to go yelling both at the eclass author, > and the devs in question about missing deps. > > Do not add this to the tree.
See above that this is already in the tree and has been for a few months (years?)
> ~harring
- -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - iQIcBAEBAgAGBQJMQl7jAAoJEC8ZTXQF1qEPQuIQANWeUwpZFNfsY6wkDWCOI+xR p4sYPRiHStY4nCJ6IZ/DGvBNnrvo+KDn3P5vT9uHT4x50cE5bYeyz4l+DCjXYtCp ey7rGL3P7l9vNtf6Vg7+8imaGbgGnr2mZQ8Pmn1ZWXaYW8i2e5yyTeUpvqH3TH2v ASKYIg5VlS3MeiP2unOQfuLXqRDcyXxMPnG6xj3pl2PpGMT3X+rAAkLDqGKRcZJj 7uA0oVUdjWM5HTKqZKYRbYpLo5veawVC+FMR4Z4DA6yhgtYsUQ+mTYnfjGgavCah KU881TUaZQajDSXVK4m1V8q8Zg0ge0vjeXN15CPhPFfnSyCqf6GbkPZE7OjizJdu vA8uoYjEMNXTAnE+TS1h18I+Cs3rL8CA+sxbHZgING5cfg8DtfRRW02zJzicaLxP tIlotZpefEKWrTBKPrfGjhk0Te/IjvUAyLfx77Q5qqKxihBxy9T0DSe7TA0Azwkk B9eW9Cn1UeoHeV1M+/kD4oXna+d66rOHLXP7LerQjm7ZqII5MwGRA7yC7RhGDyvO oCsOCii9iuBR5n+qc8dvlN9oYyrVuDE22a4LsBGSXIse9Z8C1fBayUwYTkbAJLA0 uKqYvElfvJoH9hjJud01iQtQ7GxTEdlT0HaeV085Tvq6D/eoK1U+tGlTeFZXNkFb +6R9ncUuA0AeKcfVvJ2P =8vjx -----END PGP SIGNATURE-----


Subject Author
Re: [gentoo-dev] New eclass: autotools-utils.eclass Brian Harring <ferringb@×××××.com>
Re: [gentoo-dev] New eclass: autotools-utils.eclass Maciej Mrozowski <reavertm@×××××.com>
Re: [gentoo-dev] New eclass: autotools-utils.eclass Alexis Ballier <aballier@g.o>