On Fri, 31 Dec 2010 18:34:03 -0600
Ryan Hill 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
On Fri, 31 Dec 2010 12:02:32 +0100
Ulrich Mueller 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 f
On 12/31/2010 03:38 PM, Rich Freeman wrote:
On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysinger 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 ten
On 12/31/2010 12:42 PM, Enrico Weigelt 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 n
On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysinger 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 mai
> ...
> 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.
On Fri, 31 Dec 2010 21:42:32 +0100
Enrico Weigelt 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 info
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.
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
hav
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 wil
> "MF" == Mike Frysinger 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
* 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 soo
On Fri, 31 Dec 2010 12:02:32 +0100
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.
I don't see a reaso
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
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 wo
On Fri, Dec 31, 2010 at 03:57:21PM +0100, Enrico Weigelt wrote:
> * Enrico Weigelt 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 `p
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
* Ulrich Mueller 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
* Enrico Weigelt 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
* 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.
cu
--
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 c
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
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 warn
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 whenev
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
25 matches
Mail list logo
