Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 16:46 Fri 31 Dec , Paweł Hajdan, Jr. wrote: On 12/31/10 12:13 PM, Petteri Räty wrote: EAPI 0 might stick around for quite a while but for example deprecating EAPI 1 shouldn't be as hard. That seems also to be a safe first step. EAPI-1 ebuilds were at least written with EAPIs in mind. That's obviously not true for EAPI-0. We could even deprecate EAPI-2 in favor of EAPI-3, hmmm I think a repoman non-fatal warning would be fine. If we have a warning about forcing -j1, we can surely have one about ancient EAPIs. I'm in favor of documenting things such that the latest EAPI is the standard and others are backwards diffs based on it, shifted to appendices or somewhere out of the way. This will encourage people to easily use the latest developments rather than trying to build up a mental stack of added and removed features across multiple levels. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpoajUBHwB8n.pgp Description: PGP signature
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
We have to be precise about what we are talking here: 1) for NEW ebuilds added to the tree... So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. it would definitely make sense to trigger a warning whenever an ancient EAPI is used. Remember, we're adding new features so we can use them - and we also want to train new recruits for using these features. So, I'm for a repoman warning for NEW ebuilds whenever EAPI(CURRENT_EAPI-1). This would at the moment deprecate EAPI=0,1 (and soon also 2). 2) for existing ebuilds... ... it is indeed impractical to force EAPI=0 rewriting. Some of the in-between steps however should be deprecated. Eg. EAPI=1 and later EAPI=2... My 2ct... Cheers, Andreas -- Andreas K. Huettel dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
Le 31/12/2010 17:04, Brian Harring a écrit : Quick scan of the tree via `pinspect eapi_usage`, the percentile is eapi: '0' 13934 pkgs found, 50.43% of the repository eapi: '2' 8679 pkgs found, 31.41% of the repository eapi: '3' 4432 pkgs found, 16.04% of the repository eapi: '1' 583 pkgs found, 2.11% of the repository Based on those stats, I would definitely deprecated EAPI 1 since it's almost unused, and EAPI 2 since its behavior is really close to EAPI 3. As others have mentioned, only for _new_ ebuilds. My 2¢, Rémi
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On Fri, 31 Dec 2010, Jeroen Roovers wrote: I don't see a reason to deprecate an EAPI, unless you are out to stop a specific feature from being used that was introduced in a later EAPI and breaks the earlier EAPI. Those ebuilds should be converted or otherwise taken care of, but it still wouldn't deprecate the older EAPI as a whole. The package manager has to support all EAPIs indefinitely. And it also doesn't make sense to convert existing ebuilds when half of the tree is still at EAPI 0. The suggestion is that EAPI = 2 should be used for _new_ ebuilds. And yes, the old EAPIs are a burden. For example, changing reverse dependencies if USE dependencies are needed. It's no fun if half of the affected ebuilds have to be changed from EAPI 0 to EAPI 2 in such a case. Ulrich
[gentoo-dev] Deprecate EAPIs 0 and 1?
Hi, after approval of EAPI 4, there are now 5 different EAPIs available, and it's hard to remember what features are offered by which EAPI. So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. At a later time, the warning could be changed to an error. When most of the tree has been updated to EAPI 2 or newer, we could also think about actively converting the remaining ebuilds. (Currently this doesn't look feasible though, as about half of the tree is still at EAPI=0. [1]) Opinions? Ulrich [1] http://blogs.gentoo.org/alexxy/2010/11/06/some-interesting-stats-about-gentoo-portage-tree/
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/2010 01:02 PM, Ulrich Mueller wrote: Hi, after approval of EAPI 4, there are now 5 different EAPIs available, and it's hard to remember what features are offered by which EAPI. So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. First we need to be sure that all relevant eclasses support upgrading to EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some eclasses are too. But I do second the idea of trying to limit the set of active EAPIs in the tree. Please open a repoman bug if there are no objections. At a later time, the warning could be changed to an error. When most of the tree has been updated to EAPI 2 or newer, we could also think about actively converting the remaining ebuilds. (Currently this doesn't look feasible though, as about half of the tree is still at EAPI=0. [1]) EAPI 0 might stick around for quite a while but for example deprecating EAPI 1 shouldn't be as hard. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/2010 03:13 AM, Petteri Räty wrote: First we need to be sure that all relevant eclasses support upgrading to EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some eclasses are too. As an example of things to look for, I've noticed that migration to EAPI 2 or later of any ebuild that inherits linux-mod_src_compile() will trigger the following QA Notice from econf: QA Notice: econf called in src_compile instead of src_configure -- Thanks, Zac
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/10 12:02, Ulrich Mueller wrote: Hi, after approval of EAPI 4, there are now 5 different EAPIs available, and it's hard to remember what features are offered by which EAPI. So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. That's a good idea. As long as there's a clean upgrade path from eapi0 left I'm all for it (and that is fragile - for example bash-completion has no eapi0 versions left, so currently it's really ugly to upgrade portage on an old install) At a later time, the warning could be changed to an error. When most of the tree has been updated to EAPI 2 or newer, we could also think about actively converting the remaining ebuilds. (Currently this doesn't look feasible though, as about half of the tree is still at EAPI=0. [1]) Since there's currently no need many ebuilds have never been upgraded. If people started actively working on it we could get that done in a short timeframe - but then I wonder if it's worth the effort.
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
* Enrico Weigelt weig...@metux.de schrieb:
Sorry, forgot the attachement ;-o
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
#!/bin/bash
TREE=/usr/portage
warn_eapi_missing() {
echo $1: missing EAPI= line
true
}
warn_eapi_unquoted() {
echo $1: EAPI= line not quoted
true
}
warn_eapi_deprecated() {
echo $1: EAPI $2 deprecated
true
}
check_eapi() {
while read f ; do
if ! grep EAPI= $f /dev/null ; then
warn_eapi_missing $f
elif ! grep EAPI=\ $f /dev/null ; then
warn_eapi_unquoted $f
elif grep -E EAPI\=(0|\0\) $f /dev/null; then
warn_eapi_deprecated $f 0
elif grep -e EAPI\=(1|\1\) $f /dev/null; then
warn_eapi_deprecated $f 1
# elif grep -E EAPI\=(2|\2\) $f /dev/null; then
# warn_eapi_deprecated $f 2
# elif grep -E EAPI\=(3|\3\) $f /dev/null; then
# warn_eapi_deprecated $f 3
# elif grep -E EAPI\=(4|\4\) $f /dev/null; then
# warn_eapi_deprecated $f 4
else
true
fi
done
}
find $TREE -name *.ebuild | check_eapi
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
* Ulrich Mueller u...@gentoo.org schrieb: Hi, after approval of EAPI 4, there are now 5 different EAPIs available, and it's hard to remember what features are offered by which EAPI. So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. Is there a way to scan automatically for ebuilds with older EAPIs w/o actually running emerge ? Is grep'ing sufficient ? Just hacked up a little scan script ... see attachement. At a later time, the warning could be changed to an error. When most of the tree has been updated to EAPI 2 or newer, we could also think about actively converting the remaining ebuilds. (Currently this doesn't look feasible though, as about half of the tree is still at EAPI=0. [1]) IMHO, when an EAPI is declared depcreated, new or changed ebuilds should not use it anymore. Deprecation should not happen as long as base packages still use it. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/10 12:13 PM, Petteri Räty wrote: EAPI 0 might stick around for quite a while but for example deprecating EAPI 1 shouldn't be as hard. That seems also to be a safe first step. EAPI-1 ebuilds were at least written with EAPIs in mind. That's obviously not true for EAPI-0. We could even deprecate EAPI-2 in favor of EAPI-3, hmmm I think a repoman non-fatal warning would be fine. If we have a warning about forcing -j1, we can surely have one about ancient EAPIs. Paweł Hajdan, Jr. P.S. I'm excited to see the progress with PMS and new EAPIs being more and more convenient and addressing frequent annoyances or deficiencies! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On Fri, Dec 31, 2010 at 03:57:21PM +0100, Enrico Weigelt wrote: * Enrico Weigelt weig...@metux.de schrieb: Sorry, forgot the attachement ;-o This doesn't pick up eclasses, fails on EAPI='1', and generally, isn't the best way- use proper tools please, they exist for a reason. Quick scan of the tree via `pinspect eapi_usage`, the percentile is eapi: '0' 13934 pkgs found, 50.43% of the repository eapi: '2' 8679 pkgs found, 31.41% of the repository eapi: '3' 4432 pkgs found, 16.04% of the repository eapi: '1' 583 pkgs found, 2.11% of the repository Considering eapi1 basically just added slot deps... honestly I'd deprecate it in favor of 2. If you want a breakdown of the eapi per cpv, use pquery --raw --repo /path/to/your/rsync --all --attr eapi ~harring pgphdKCwK8ZeC.pgp Description: PGP signature
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On Friday, December 31, 2010 06:02:32 Ulrich Mueller wrote: So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. personally, i dont see a problem here. what actual burden is there for continuing supporting EAPI 0/1 ? i dont think we should go around deprecating things for the pure fun of it. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On Fri, 31 Dec 2010 12:02:32 +0100 Ulrich Mueller u...@gentoo.org wrote: So maybe it's about time that we deprecate EAPIs 0 and 1 for new ebuilds. As a first step, a warning could be added to repoman that would be triggered whenever a new ebuild with an EAPI less than 2 is committed. I don't see a reason to deprecate an EAPI, unless you are out to stop a specific feature from being used that was introduced in a later EAPI and breaks the earlier EAPI. Those ebuilds should be converted or otherwise taken care of, but it still wouldn't deprecate the older EAPI as a whole. jer
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysinger vap...@gentoo.org wrote: personally, i dont see a problem here. what actual burden is there for continuing supporting EAPI 0/1 ? i dont think we should go around deprecating things for the pure fun of it. -mike I tend to agree, unless of course the maintainers of the various package managers chime in and say that some aspect of some particular EAPI requires them to maintain a lot of legacy code. Then I'd be all for dropping some. However, with upwards of 70%+ of the tree being pre-EAPI-3, do we really want to go around tweaking all those ebuilds just so that they work exactly like they already work (if we don't mess anything up)? I'm sure lots of packages are maintainer-needed, so are we going to do a massive removal of otherwise-working packages just because of their EAPI (Im fine with cleaning broken packages, but why touch working ones)? Sure, the new EAPIs are nice, and I'm sure that devs creating new ebuilds will follow whatever is in the devmanual (which obviously would only reference the new way of doing things) so over time things will take care of themselves. Why force a change? Again, if this is causing the package manager / repoman / etc maintainers problems, then I'm fine with simplifying the landscape... Rich
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/2010 03:38 PM, Rich Freeman wrote: On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysingervap...@gentoo.org wrote: personally, i dont see a problem here. what actual burden is there for continuing supporting EAPI 0/1 ? i dont think we should go around deprecating things for the pure fun of it. -mike I tend to agree, unless of course the maintainers of the various package managers chime in and say that some aspect of some particular EAPI requires them to maintain a lot of legacy code. Then I'd be all for dropping some. I'm not a gentoo dev, but I tend to agree here. If it ain't broke, don't fix it. Later, Gizmo
