Re: [gentoo-dev] EAPI 4 specification approved
On 12/30/2010 07:37 AM, Petteri Räty wrote: As the text was just approved it will take a while before Package Managers release new versions that declare support for EAPI 4. As such, the new EAPI 4 can't yet be used in the main tree. You will be notified as soon as you can start reaping the benefits. There are portage-2.1.9.27 and 2.2.0_alpha11 releases with EAPI 4 support in the tree now. Please test them. -- Thanks, Zac
[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] epatch: reject patches with relative paths
* Mike Frysinger vap...@gentoo.org schrieb: sounds like overkill. people will file bugs and they'll get fixed. once it goes fatal, people will fix even faster. i dont plan on making it fatal anytime soon. An option to make it fatal would be helpful. 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?
* 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] epatch: reject patches with relative paths
On Friday, December 31, 2010 09:16:27 Enrico Weigelt wrote: * Mike Frysinger vap...@gentoo.org schrieb: sounds like overkill. people will file bugs and they'll get fixed. once it goes fatal, people will fix even faster. i dont plan on making it fatal anytime soon. An option to make it fatal would be helpful. no, it wouldnt -mike signature.asc Description: This is a digitally signed message part.
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] epatch: reject patches with relative paths
* Mike Frysinger vap...@gentoo.org schrieb: On Friday, December 31, 2010 09:16:27 Enrico Weigelt wrote: * Mike Frysinger vap...@gentoo.org schrieb: sounds like overkill. people will file bugs and they'll get fixed. once it goes fatal, people will fix even faster. i dont plan on making it fatal anytime soon. An option to make it fatal would be helpful. no, it wouldnt Dont you wanna let users decide themselfes whether they want 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] epatch: reject patches with relative paths
MF == Mike Frysinger vap...@gentoo.org writes: MF along those lines, we should start rejecting relative paths. we MF cant auto- skip the leading elements since relative paths could MF appear anywhere. You do not need .. or . in a path for it to be a relative path. :; diff -uNr a/foo b/foo generates a patch with relative paths. The warning needs to be more specific lest it cause undue confusion and support load. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] epatch: reject patches with relative paths
On Friday, December 31, 2010 14:22:31 Enrico Weigelt wrote: * Mike Frysinger schrieb: On Friday, December 31, 2010 09:16:27 Enrico Weigelt wrote: * Mike Frysinger schrieb: sounds like overkill. people will file bugs and they'll get fixed. once it goes fatal, people will fix even faster. i dont plan on making it fatal anytime soon. An option to make it fatal would be helpful. no, it wouldnt Dont you wanna let users decide themselfes whether they want it ? if you want to force such useless behavior, then export EPATCH_OPTS yourself -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] making revdep-rebuild (partially) obsolete
Hi folks, just a little braindump, how revdep-rebuild could be made (partially) obsolete in future: Today it might happen that on an library update an old .so file gets unmerged while still used by somebody - that's what revdep- rebuild scans for. While it should catch those cases, we still have some downtime for certain packages (in bad cases, when it broke somewhere deep in the dependency chain, rebuild might take quite a lot of time). The main problem IMHO is that portage doesn't record which libraries some package links in, so it doesn't know which ones have to be protected from unmerge (unless explicitly stated somewhere). So I'd propose to add record that information. On next merge, this information can be used for an automatic library-protect. This would also record which libraries have been protected from removal and for whom. Subsequent merges will update this that, and once all importers have been unmerged, depclean can clean up the leftover dirt. What do you think about this idea ? 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] making revdep-rebuild (partially) obsolete
On 12/31/2010 03:42 PM, Enrico Weigelt wrote: What do you think about this idea ? I think you should check out the preserve-libs feature in portage-2.2.
Re: [gentoo-dev] making revdep-rebuild (partially) obsolete
On Fri, 31 Dec 2010 21:42:32 +0100 Enrico Weigelt weig...@metux.de wrote: The main problem IMHO is that portage doesn't record which libraries some package links in, so it doesn't know which ones have to be protected from unmerge (unless explicitly stated somewhere). So I'd propose to add record that information. On next merge, this information can be used for an automatic library-protect. This would also record which libraries have been protected from removal and for whom. Subsequent merges will update this that, and once all importers have been unmerged, depclean can clean up the leftover dirt. What do you think about this idea ? You mean what do we think about portage-2.2 and preserved-libs? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] making revdep-rebuild (partially) obsolete
... Subsequent merges will update this that, ... Subsequent merges may happen after a long while. Old, possibly vulunerable library will still be used, and most likely unseen by admin.
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
[gentoo-dev] Re: Deprecate EAPIs 0 and 1?
On Fri, 31 Dec 2010 12:02:32 +0100 Ulrich Mueller u...@gentoo.org wrote: Opinions? I don't mind a warning, but I'll tell you right now there is no way I'm using anything other than EAPI 0 for toolchain packages. Mike might disagree but I don't think anyone feels like rewriting and auditing toolchain.eclass for zero benefit. I thought there was a consensus that we wouldn't use anything other than EAPI 0 for @system packages, but it appears python ignored that and others followed suit. EAPI 1 I could live without. But I think EAPI 0, being the base on which all other EAPIs are defined, needs to stick around indefinitely. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Deprecate EAPIs 0 and 1?
On Fri, 31 Dec 2010 18:34:03 -0600 Ryan Hill dirtye...@gentoo.org wrote: I thought there was a consensus that we wouldn't use anything other than EAPI 0 for @system packages, but it appears python ignored that and others followed suit. Oh $deity yeah. jer
