[gentoo-dev] Re: mbox -- looks sort of interesting

[Michael Palimaka]

On 02/11/2014 11:36 AM, Jason A. Donenfeld wrote:
> Hey folks,
> 
> Late night clicking-while-drooling, I came across something a few
> minutes ago that mildly piqued my interest -- mbox
> . It's a sandbox that uses a
> combination of ptrace and seccomp bpf; neither ours nor exherbo's uses
> both of these together. The killer feature, for us, that's motivating
> me to write to this list, is that it creates a "shadow file system",
> and then has the option to commit the changes of that file system to
> the real file system, piece by piece, when the process is done. It
> made me think of some discussions we had at FOSDEM about Portage
> evolution and whatnot. I haven't looked at this tool past an initial
> glance, but it does look like interesting food for thought.
> 
> Jason
> 

Looks interesting. It reminds me somewhat of autodep[1].

[1]: http://soc.dev.gentoo.org/~bay/autodep/intro.html

Re: [gentoo-dev] mbox -- looks sort of interesting

[Michael Haubenwallner]

On 02/11/14 01:36, Jason A. Donenfeld wrote:
> Hey folks,
> 
> Late night clicking-while-drooling, I came across something a few
> minutes ago that mildly piqued my interest -- mbox
> . It's a sandbox that uses a
> combination of ptrace and seccomp bpf; neither ours nor exherbo's uses
> both of these together. The killer feature, for us, that's motivating
> me to write to this list, is that it creates a "shadow file system",
> and then has the option to commit the changes of that file system to
> the real file system, piece by piece, when the process is done. It
> made me think of some discussions we had at FOSDEM about Portage
> evolution and whatnot. I haven't looked at this tool past an initial
> glance, but it does look like interesting food for thought.

Sounds interesting, especially the "without special privileges" bit...

/haubi/

Re: [gentoo-dev] dev-lang/go

[yac]

On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway  wrote:

> I really like working with Go, and would like to see a means of
> merging Go packages with Portage. In short I am asking if anyone else
> is interested in a Go project.

I might be. I have packaged something for private use but it just a
bunch of hacks. Anyway, I have some production go code.

>
> For those who aren't familiar with Go, I will sumarise why Portage and
> Go do not play well together.
>
> Go is static linked by default.
> The Go compiler creates static libraries and binaries. Libraries
> compilied with different versions of Go (1.1/1.2) may not be linked
> into the same binary.

Haskell is staticaly linked as well (by default) and you can see the
gentoo haskell project. I don't see this as a problem, we just will have
all dependencies in DEPEND and will have to scope on the go compiler
version under something like /usr/lib/go-1.{1,2}/...

I'd just copy the python herd approach (use flags, filesystem scoping
and having binary wrapper).

> It is possible to compile dynamicly and that may involve using the
> GCC frontend, which is probably less tested and less optimized.

I'd just skip over this unless someone is really interested in this one,
in which case this could be explicitly enabled by a use flag or
something.

>
> Go libraries are usually unversioned.
> Libraries outside the system library are resolved with an import
> statement that specifies a source code repository, such as a git or
> mecurial repository. Most often Go libraries are installed using the
> 'go get' tool that clones a repository, and simply assumes HEAD/tip is
> the best revision to build against. There is some support for using
> git tags but it is not well documented. Often these libraries are very
> small for the sake of reuse and to keep APIs simple.

In this case we just have to require upstream to make releases or
publish either live ebuilds, or ebuilds versioned something like
0_pre-MM-DD.ebuild [1]

I know part of the gopher commnity doesn't see this as a problem but I
believe the big players recognize this and there is an effort to come up
with a solution.

> If all that sounds bad, thats because it is. Is it worth versioning
> many tiny libraries or do we simply cache the repositiories and blame
> upstream when things stop compiling?

I'd certainly want to have versions where available.

>
> A have made an eclass for Go and an ebuild for the bitcoin node
> written in pure Go to atleast prove that all this is possible. These
> are in the 'emery' overlay:
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd
>
> The eclass it a bit of a mess but it works, having done that, I would
> say that making ebuilds for every go library is tedious, but can be
> done almost entirely with boilerplate, almost every time.
>
> The eclasss installs go source and static libraries
> to /usr/lib/go/gentoo (source code and .a library are required to
> link). The problem is when Go is updated, this folder may get wiped
> out, and if it isn't, those libraries will be incompatable with the
> new release anyway.

How come it gets wiped? That just shouldn't happen.

> The other solution I see is to make a Go directory in /var/cache or

I don't think this is a good idea as I think it would be surprising to
users to find libraries elsewhere than /usr/lib and I believe /var/cache
specificaly even violates FHS.

> something like it and just manage it as a cache.
> Libraries may come and go but that is fine.

I might want to have a library just for development and I'd wouldn't
like it disappearing.

> Bare repositories may be cached in DISTDIR
> just like the git and mercurial eclasses do. Doing things this way may
> require a specific utility for Portage that wraps the Go toolchain,
> which I would be willing to create. This utility could probably
> automatically resolve and fetch the libraries that are required

Building the library/package shouldn't/mustn't (what does the PMS
say?) require network access once the sources are fetched.

> as opposed to making an ebuild for each library, but that raises the
> problem of assuming the developers of each library maintain consistant
> quality and security.

Every ebuild that gets to gentoo official must meet basic standard of
quality. That's no different for golang.

>
>
> The problem is Go makes it trivial to build from source, but it does
> that in a very different and less precise way than Gentoo. There is
> always the option of build bots and installing binaries to /opt...
>
>
> Emery
>

I think it would be good idea to start a separate gentoo-golang
repository (github?) and treat it more (to keep it aligned with the way
gentoo works) or less (to speed up the development) as if it were gx86.

In the organization part, I think we could inspire ourself in the

[gentoo-dev] mbox -- looks sort of interesting

[Jason A. Donenfeld]

Hey folks,

Late night clicking-while-drooling, I came across something a few
minutes ago that mildly piqued my interest -- mbox
. It's a sandbox that uses a
combination of ptrace and seccomp bpf; neither ours nor exherbo's uses
both of these together. The killer feature, for us, that's motivating
me to write to this list, is that it creates a "shadow file system",
and then has the option to commit the changes of that file system to
the real file system, piece by piece, when the process is done. It
made me think of some discussions we had at FOSDEM about Portage
evolution and whatnot. I haven't looked at this tool past an initial
glance, but it does look like interesting food for thought.

Jason

-- 
Jason A. Donenfeld
Gentoo Linux Security & Infrastructure
zx...@gentoo.org
www.zx2c4.com

Re: [gentoo-dev] gentoo-x86 and git

[Rich Freeman]

On Mon, Feb 10, 2014 at 7:00 PM, yac  wrote:
> While you are it, it would be great if you could get some stats on
> frequency of commits. Especially with reagrd to the planned cvs -> git
> migration since this might cause some issues/inconvenience if the whole
> portage will be one git repo.

Oh, commits are plenty frequent.  As of the last migrated git tree I
have which is almost exactly a year old there were 2.8M commits, with
300k in 2012.  If you want the breakdown by hour (UTC I think - or
whatever msql does by default) it is:
count(`key`) HOUR(FROM_UNIXTIME(`timestamp`))
6259 0
6108 1
8329 2
11029 3
14102 4
13289 5
12087 6
13351 7
15224 8
15901 9
17395 10
19710 11
18912 12
17924 13
23717 14
18836 15
15666 16
12808 17
10589 18
6155 19
5197 20
5018 21
5906 22
6508 23

So, divide those figures by 365 and that is the daily rate in each of
those hour bins.

I have a mysql table of cvs commits so if there is some particular
query you're looking for let me know.  Given a full tarball of the cvs
tree (rcs files) I could update it if necessary.  If you wanted to
know the hourly rate on a typical Sat I could probably tell you.

Rich

Re: [gentoo-dev] gentoo-x86 and git

[Alec Warner]

On Mon, Feb 10, 2014 at 4:00 PM, yac  wrote:

> On Mon, 10 Feb 2014 20:33:27 +0800
> Patrick Lauer  wrote:
>
> > Ahoi,
> >
> > I've been looking for a clean git-converted gentoo-x86 repo for ...
> > well ... mostly data mining as cvs / anoncvs.g.o is too slow for some
> > things.
> >
>
> While you are it, it would be great if you could get some stats on
> frequency of commits. Especially with reagrd to the planned cvs -> git
> migration since this might cause some issues/inconvenience if the whole
> portage will be one git repo.
>

You can fetch the CVS repo history over rsync and parse it yourself; this
information is already available ;p

-A


>
>
> ---
> Jan Matějka| Gentoo Developer
> https://gentoo.org | Gentoo Linux
> PG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
>

Re: [gentoo-dev] gentoo-x86 and git

[yac]

On Mon, 10 Feb 2014 20:33:27 +0800
Patrick Lauer  wrote:

> Ahoi,
> 
> I've been looking for a clean git-converted gentoo-x86 repo for ...
> well ... mostly data mining as cvs / anoncvs.g.o is too slow for some
> things.
> 

While you are it, it would be great if you could get some stats on
frequency of commits. Especially with reagrd to the planned cvs -> git
migration since this might cause some issues/inconvenience if the whole
portage will be one git repo.


---
Jan Matějka| Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B


signature.asc
Description: PGP signature

Re: [gentoo-dev] gentoo-x86 and git

[Alec Warner]

On Mon, Feb 10, 2014 at 1:17 PM, Robin H. Johnson wrote:

> On Mon, Feb 10, 2014 at 08:33:27PM +0800, Patrick Lauer wrote:
> > Ahoi,
> >
> > I've been looking for a clean git-converted gentoo-x86 repo for ... well
> > ... mostly data mining as cvs / anoncvs.g.o is too slow for some things.
> >
> > This has been needlessly challenging, which confuses me a bit.
> >
> > First, a little complaint:
> >
> > There used to be some data at git-exp.overlays.gentoo.org, but that
> > machine has vanished. Ok, stuff happens, but that's not motivating.
> That physical host was made into the new home of overlays.g.o when the
> previous host died. The content is still available.
>
> > Anoncvs.g.o is bouncing up and down a lot, so just getting the raw cvs
> > repo to do a local conversion is somewhere between needlessly hard and
> > impossible.
> Even with the move to anonvcs being separated from sources.g.o last
> week?
>

I made it work, then it was rebooted for maintenance and broke again (the
chroots were missing from fstab.)
It is functioning now and no one has filed a bug report with sufficient
detail of the deficiencies they are experiencing; plus it works for me when
I try it. I asked Patrick to file a more detailed report than 'hey anoncvs
is not working again.'

-A


>
> > The gentoo-scm mailinglist has mostly fallen asleep, but even the stuff
> > discussed there doesn't seem to exist in a public repo that can be found
> > without telepathy skills.
> ...
> > I'd appreciate it if people that worked on the conversion would point me
> > at the scripts and documentation they used; I'd appreciate a proper
> > 'official' repo to collect such things; and it'd be really useful to
> > have the work-in-progress converted repo online so that people can
> > experiment with it.
> I'm going to document what's last on there, as well as in my head onto
> the wiki.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Infrastructure Lead
> E-Mail : robb...@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>
>

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Alan McKinnon]

On 10/02/2014 22:56, Alec Warner wrote:
> On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon  > wrote:
> 
> On 10/02/2014 18:05, Ulrich Mueller wrote:
> >> Removing support for it from a package manager should of course
> >> > happen much later (well after it is banned).
> > The package manager must be able to uninstall old packages, which
> > essentially means that support for old EAPIs cannot be removed.
> 
> 
> I feel this aspect needs to be limited, no user can reasonably expect
> Gentoo devs to retain support in the package manager for obsolete
> features indefinitely. We also shouldn't be too hasty in removing the
> support, but there has to be a cut-off point somewhere, a point of no
> return. It's probably measured in years, my thumb suck guess is 3 years
> after a given EAPI is finally obsoleted.
> 
> 
> Why is that unreasonable?

It's unreasonable for me to expect you to support long-dead features and
EAPIs. Unless you choose to support them of course, or if it's no big
deal to support them (I have a hunch this last is not true, that it is a
big deal actually).

The bottom line is that I don't pay you to write the pm I use, so I have
no expectation that stuff will always work forever. A host where portage
has not been updated for 2 years is basically a moribund host



> 
> -A
> 
>  
> 
> 
> As a real example - I know someone who proudly shows off a Gentoo host
> with a 2004 profile. Can he reasonably expect portage to still work
> flawlessly 10 years later? I feel no, luckily he agrees with me.
> 
> --
> Alan McKinnon
> alan.mckin...@gmail.com 
> 
> 
> 


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-dev] gentoo-x86 and git

[Robin H. Johnson]

On Mon, Feb 10, 2014 at 08:33:27PM +0800, Patrick Lauer wrote:
> Ahoi,
> 
> I've been looking for a clean git-converted gentoo-x86 repo for ... well
> ... mostly data mining as cvs / anoncvs.g.o is too slow for some things.
> 
> This has been needlessly challenging, which confuses me a bit.
> 
> First, a little complaint:
> 
> There used to be some data at git-exp.overlays.gentoo.org, but that
> machine has vanished. Ok, stuff happens, but that's not motivating.
That physical host was made into the new home of overlays.g.o when the
previous host died. The content is still available.

> Anoncvs.g.o is bouncing up and down a lot, so just getting the raw cvs
> repo to do a local conversion is somewhere between needlessly hard and
> impossible.
Even with the move to anonvcs being separated from sources.g.o last
week?

> The gentoo-scm mailinglist has mostly fallen asleep, but even the stuff
> discussed there doesn't seem to exist in a public repo that can be found
> without telepathy skills.
...
> I'd appreciate it if people that worked on the conversion would point me
> at the scripts and documentation they used; I'd appreciate a proper
> 'official' repo to collect such things; and it'd be really useful to
> have the work-in-progress converted repo online so that people can
> experiment with it.
I'm going to document what's last on there, as well as in my head onto
the wiki.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Alec Warner]

On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon wrote:

> On 10/02/2014 18:05, Ulrich Mueller wrote:
> >> Removing support for it from a package manager should of course
> >> > happen much later (well after it is banned).
> > The package manager must be able to uninstall old packages, which
> > essentially means that support for old EAPIs cannot be removed.
>
>
> I feel this aspect needs to be limited, no user can reasonably expect
> Gentoo devs to retain support in the package manager for obsolete
> features indefinitely. We also shouldn't be too hasty in removing the
> support, but there has to be a cut-off point somewhere, a point of no
> return. It's probably measured in years, my thumb suck guess is 3 years
> after a given EAPI is finally obsoleted.
>

Why is that unreasonable?

-A



>
> As a real example - I know someone who proudly shows off a Gentoo host
> with a 2004 profile. Can he reasonably expect portage to still work
> flawlessly 10 years later? I feel no, luckily he agrees with me.
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>

Re: [gentoo-dev] gentoo-x86 and git

[Alec Warner]

On Mon, Feb 10, 2014 at 4:33 AM, Patrick Lauer  wrote:

> Ahoi,
>
> I've been looking for a clean git-converted gentoo-x86 repo for ... well
> ... mostly data mining as cvs / anoncvs.g.o is too slow for some things.
>
> This has been needlessly challenging, which confuses me a bit.
>
> First, a little complaint:
>
> There used to be some data at git-exp.overlays.gentoo.org, but that
> machine has vanished. Ok, stuff happens, but that's not motivating.
>
> Anoncvs.g.o is bouncing up and down a lot, so just getting the raw cvs
> repo to do a local conversion is somewhere between needlessly hard and
> impossible.
>

As I had initially advised, you can rsync the entire CVS repo and do the
entire conversion locally using cvs pserver. You don't need to rely on
anoncvs. As you have noticed, it doesn't exactly have high marks for
uptime. Plus a local conversation is much faster; you don't get the network
latency for all the cvs operations.

-A


>
> The gentoo-scm mailinglist has mostly fallen asleep, but even the stuff
> discussed there doesn't seem to exist in a public repo that can be found
> without telepathy skills.
>
> So ... well ... if it's that hard to just find out the state of the last
> experiments there won't be much contribution.
>
> There is a git repository at https://bitbucket.org/lmnd/gentoo-x86 - but
> (1) it has truncated history and (2) it diverges by >1500 files from
> gentoo-x86 for the last week. So that's mostly useless for data mining.
> (I haven't tried figuring out how it diverges, but raw ebuild count is
> +1600 for "yesterday", so that's baad)
>
> I'd appreciate it if people that worked on the conversion would point me
> at the scripts and documentation they used; I'd appreciate a proper
> 'official' repo to collect such things; and it'd be really useful to
> have the work-in-progress converted repo online so that people can
> experiment with it.
>
> (If anyone needs webspace or similar for that, well, I run lots of cruft
> anyways, so another annoying thing won't matter ...)
>
> Thanks for your support,
>
> Patrick
>
> P.S. If anyone feels an overwhelming urge to point out the irony ...
> don't ;)
>
>

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Lars Wendler]

On Mon, 10 Feb 2014 21:46:56 +0800 Patrick Lauer wrote:

>On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
>> The statement "Deprecating an EAPI can mean breakage" depends on
>> what we mean by "deprecating."  I'm assuming here we mean something
>> like repoman won't allow commits at EAPI=1,2,3 but that ebuilds in
>> the tree at those EAPI's will continue working.  Eg. dosed which was
>> deprecated in the EAPI 3 to 4 jump.
>
>Right now EAPI 1 and 2 are deprecated, which means repoman prints some
>warnings that get ignored and nothing happens.

Not in my case. I EAPI-bump each ebuild to either EAPI-4
(base-system packages) or EAPI-5 where repoman complains about when I
put my fingers on them...
I hope I am not the only one doing this.

>Going from the current state I would distinguish between deprecated
>(=unwanted, but tolerated) and banned (not tolerated)
>
>> 
>> I think we should look at the question of deprecating EAPI's on and
>> ad hoc basis with discussion on the list and a vote in the council.
>
>I think it's safe to deprecate the antepenultimate EAPI, and then do
>the banning on a more delayed and controlled basis.
>
>Patrick
>
>

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 12:20 PM, Tom Wijsman  wrote:
> On Mon, 10 Feb 2014 17:05:22 +0100
> Ulrich Mueller  wrote:
>> The package manager must be able to uninstall old packages, which
>> essentially means that support for old EAPIs cannot be removed.
>
> That's only a subset of the entire EAPI, which could be separately
> still supported; while no longer supporting the majority of it, for
> example, whether src_prepare is supported doesn't really matter anymore
> when you are uninstalling a package. One could make up a list; however,
> it's not a problem yet, it might become one in 10 years or so...

Well, that strikes me as a cross-that-bridge-when-we-get-to-it
problem.  However, if maintaining the code becomes a problem we could
always create a script that finds and re-installs any package that
uses an about-to-be-desupported EAPI and then the system will be clean
of them.  It doesn't sound nearly as bad as that glibc upgrade that
broke the ABI a decade ago, and it would only impact packages that
hadn't been otherwise updated in a long time...

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 17:05:22 +0100
Ulrich Mueller  wrote:

> > On Mon, 10 Feb 2014, Rich Freeman wrote:
> 
> > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller 
> > wrote:
> >> I'd rather argue in terms of time instead of version numbers,
> >> because of the upgrade path for old systems. We guarantee one year
> >> for stable systems, but IMHO we should be more conservative for
> >> EAPI deprecation and go for two or three years there.
> 
> > By EAPI deprecation it is meant that we discourage using the old
> > EAPI in the tree.
> 
> Right, the above was about ebuilds in the tree, not about package
> managers. At least sys-apps/portage and its dependencies must stay at
> an EAPI that is stable long enough to allow an upgrade of old systems
> (where Portage might not recognise the newest EAPI).

Yes, besides the way we deprecate it we should also be clear in our
wording what this all pertains to; a broad statement can has its effect
in the Portage tree, the package manager, the upgrade path, the vdb and
possibly more. Otherwise we get what Patrick describes; a warning in
repoman, with nearly no progress wrt its removal in the Portage tree.

> > Removing support for it from a package manager should of course
> > happen much later (well after it is banned).
> 
> The package manager must be able to uninstall old packages, which
> essentially means that support for old EAPIs cannot be removed.

That's only a subset of the entire EAPI, which could be separately
still supported; while no longer supporting the majority of it, for
example, whether src_prepare is supported doesn't really matter anymore
when you are uninstalling a package. One could make up a list; however,
it's not a problem yet, it might become one in 10 years or so...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 16:16:42 +
Ciaran McCreesh  wrote:

> > From my limited look at the code I've done so far in the small bit
> > of repoman work on the Portage team, as detailed in another mail I
> > just sent to you on this ML, I wouldn't consider it as a problem
> > just now.
> > 
> > We for example have /usr/lib/portage/pym/portage/eapi.py to easily
> > deal with it, it's just that such checks would drop in that file and
> > across the Portage source code when the versions listed in those
> > checks are no longer used. It's currently reasonable to have this
> > amount of checks, but imagine it growing to what you would need for
> > 10 versions; that'd be a different story, but perhaps it is too
> > early to wonder about this now.
> 
> Removing EAPIs doesn't help you: you still need to be able to
> uninstall things.

There aren't much checks left if you only need to cover that.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Alan McKinnon]

On 10/02/2014 18:05, Ulrich Mueller wrote:
>> Removing support for it from a package manager should of course
>> > happen much later (well after it is banned).
> The package manager must be able to uninstall old packages, which
> essentially means that support for old EAPIs cannot be removed.


I feel this aspect needs to be limited, no user can reasonably expect
Gentoo devs to retain support in the package manager for obsolete
features indefinitely. We also shouldn't be too hasty in removing the
support, but there has to be a cut-off point somewhere, a point of no
return. It's probably measured in years, my thumb suck guess is 3 years
after a given EAPI is finally obsoleted.

As a real example - I know someone who proudly shows off a Gentoo host
with a 2004 profile. Can he reasonably expect portage to still work
flawlessly 10 years later? I feel no, luckily he agrees with me.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ciaran McCreesh]

On Mon, 10 Feb 2014 15:58:23 +0100
Tom Wijsman  wrote:
> On Mon, 10 Feb 2014 09:41:13 -0500
> Rich Freeman  wrote:
> > On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman 
> > wrote:
> > > Well, that package maintainers are called developers on Gentoo
> > > isn't helping the interpretation here; regardless of how one
> > > defines those, both maintainers and PM implementers have to be
> > > taken into account here.
> > >
> > > From quick thoughts the latter are a bit more affected than the
> > > former, but perhaps Patrick can highlight what he sees as a
> > > burden.
> > 
> > You would think, but the reason I raised the question was that
> > historically every time this has come up the package manager
> > maintainers usually chime in and say that they don't consider it a
> > problem.  I want to do whatever I can to make them happy since we
> > are so desperately in need of more of them, but...
> 
> From my limited look at the code I've done so far in the small bit of
> repoman work on the Portage team, as detailed in another mail I just
> sent to you on this ML, I wouldn't consider it as a problem just now.
> 
> We for example have /usr/lib/portage/pym/portage/eapi.py to easily
> deal with it, it's just that such checks would drop in that file and
> across the Portage source code when the versions listed in those
> checks are no longer used. It's currently reasonable to have this
> amount of checks, but imagine it growing to what you would need for
> 10 versions; that'd be a different story, but perhaps it is too early
> to wonder about this now.

Removing EAPIs doesn't help you: you still need to be able to uninstall
things.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ulrich Mueller]

> On Mon, 10 Feb 2014, Rich Freeman wrote:

> On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller 
> wrote:
>> I'd rather argue in terms of time instead of version numbers,
>> because of the upgrade path for old systems. We guarantee one year
>> for stable systems, but IMHO we should be more conservative for
>> EAPI deprecation and go for two or three years there.

> By EAPI deprecation it is meant that we discourage using the old
> EAPI in the tree.

Right, the above was about ebuilds in the tree, not about package
managers. At least sys-apps/portage and its dependencies must stay at
an EAPI that is stable long enough to allow an upgrade of old systems
(where Portage might not recognise the newest EAPI).

> Removing support for it from a package manager should of course
> happen much later (well after it is banned).

The package manager must be able to uninstall old packages, which
essentially means that support for old EAPIs cannot be removed.

Ulrich


pgppm3oJ0Ijmk.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller  wrote:
> I'd rather argue in terms of time instead of version numbers, because
> of the upgrade path for old systems. We guarantee one year for stable
> systems, but IMHO we should be more conservative for EAPI deprecation
> and go for two or three years there.

By EAPI deprecation it is meant that we discourage using the old EAPI
in the tree.  Removing support for it from a package manager should of
course happen much later (well after it is banned).

There is always the upgrade path problem when system packages start
using the new EAPI and eventually the dependencies to do a portage
upgrade can't be installed using an old version of portage.  However,
that problem exists regardless of EAPI deprecation - it is more about
when we migrate system packages or whether we save tree/distfile
snapshots and so on.  Even if we don't deprecate the old EAPIs if
@system maintainers start bumping their packages there will eventually
be problems for users who don't update soon.

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Anthony G. Basile]

On 02/10/2014 09:35 AM, Tom Wijsman wrote:

one and possibly needed features. You will connect the question of
>"are we ready to deprecate X" with the question "we need to introduce
>Y for needed features a, b and c."

It is hard to grasp for me for when features from a newer EAPI would
delay the migration, do you have an example?



That's not what i mean.  It is possible that we may want the newer EAPI 
for the features it brings but be as yet unwilling to deprecated the 
older EAPI for stability reasons.  Even if the newer EAPI is a proper 
superset of the older, hidden implementation changes have not been 
tested well and we might want to be more caution about deprecating our 
older yet very stable EAPI.  EAPI=4 is very stable right now.  I have 
more confidence in it that 5 simply because of the coverage and testing 
its gotten.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ulrich Mueller]

> On Mon, 10 Feb 2014, Patrick Lauer wrote:

> On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
>> I think we should look at the question of deprecating EAPI's on and
>> ad hoc basis with discussion on the list and a vote in the council.

+1

> I think it's safe to deprecate the antepenultimate EAPI, and then do
> the banning on a more delayed and controlled basis.

I'd rather argue in terms of time instead of version numbers, because
of the upgrade path for old systems. We guarantee one year for stable
systems, but IMHO we should be more conservative for EAPI deprecation
and go for two or three years there.

Anyway, the Portage version supporting EAPI 4 became stable on
2011-03-17 [1], so it looks like EAPI 3 could be deprecated soon.

Ulrich

[1] https://wiki.gentoo.org/wiki/Project:PMS#EAPI_life_cycle


pgpGHWymZKtlk.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 08:34:00 -0500
Rich Freeman  wrote:

> On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer 
> wrote:
> > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
> 
> Does "adding" in this case include revbumps?

Yes; though, we kind of expect rev bumps to include multiple fixes if
possible, not just a fix for a particular bug. It is indeed kind of up
to the maintainer if he wants to include trivial fixes like EAPI bumps
and what not; though, it can be really fun when you add patches to
src_prepare in an EAPI that doesn't support src_prepare yet... :)

> > More than two supported EAPIs is an unneeded burden on developers.
> 
> Is this really a generally held belief?  I don't find it a burden that
> ebuilds in the tree may use various EAPIs.  I could see how they make
> scripted mass-updates to ebuilds more difficult, though I'm not sure
> how much of an issue this is in practice.
> 
> I could also see how supporting many EAPIs could be a burden on
> package managers, but if that is a concern I'd be interested in
> hearing from these maintainers.
> 
> My sense is that deprecating probably makes sense, but banning should
> only be done if in reaction to a particular problem.  Repoman warnings
> call attention to the issue so that the maintainer is aware and can
> take the appropriate action, but without restricting their actions.
> 
> Now, if people are actually impacted by all the EAPIs I don't mind
> pushing harder to get rid of some.

A lot of this is more of a future proof approach than to address an
actual practical problem; the ~5 or so cases we've got to support in
PMs, which are actually often just ~2 or ~3, aren't really a burden as
it stands now. But once that gets to the ~10 cases, which boils down to
often like maybe ~4 to ~6 cases; it becomes a bit more bloated up to a
point you really start yelling at code cruft, but we're still far from
as there are less often PMS releases these days.

Well, some of us also see it as code cruft in the Portage tree; also in
a way that is growing as we get more releases of the PMS, this will
probably not ever really bother maintainers (unless we expect them to
know how older EAPIs were by heart, this is comparable to how web
developers need to account for older versions of browsers) but it really
could start to bother those whom look over the whole Portage tree.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 09:41:13 -0500
Rich Freeman  wrote:

> On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman 
> wrote:
> > Well, that package maintainers are called developers on Gentoo isn't
> > helping the interpretation here; regardless of how one defines
> > those, both maintainers and PM implementers have to be taken into
> > account here.
> >
> > From quick thoughts the latter are a bit more affected than the
> > former, but perhaps Patrick can highlight what he sees as a burden.
> 
> You would think, but the reason I raised the question was that
> historically every time this has come up the package manager
> maintainers usually chime in and say that they don't consider it a
> problem.  I want to do whatever I can to make them happy since we are
> so desperately in need of more of them, but...

From my limited look at the code I've done so far in the small bit of
repoman work on the Portage team, as detailed in another mail I just
sent to you on this ML, I wouldn't consider it as a problem just now.

We for example have /usr/lib/portage/pym/portage/eapi.py to easily deal
with it, it's just that such checks would drop in that file and across
the Portage source code when the versions listed in those checks are no
longer used. It's currently reasonable to have this amount of checks,
but imagine it growing to what you would need for 10 versions; that'd be
a different story, but perhaps it is too early to wonder about this now.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman  wrote:
> Well, that package maintainers are called developers on Gentoo isn't
> helping the interpretation here; regardless of how one defines those,
> both maintainers and PM implementers have to be taken into account here.
>
> From quick thoughts the latter are a bit more affected than the former,
> but perhaps Patrick can highlight what he sees as a burden.

You would think, but the reason I raised the question was that
historically every time this has come up the package manager
maintainers usually chime in and say that they don't consider it a
problem.  I want to do whatever I can to make them happy since we are
so desperately in need of more of them, but...

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 08:23:51 -0500
"Anthony G. Basile"  wrote:

> On 02/10/2014 07:43 AM, Patrick Lauer wrote:
> > EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree
> > (EAPI 6, most likely)
> 
> I am concerned about making this a "rule".

Maybe rather a rule with exceptions, or a rather strong recommendation;
as we've seen easier, sometimes a rule needs a revision.

> While I think its okay for the 4/5/6 move, I'm not sure if it will
> always be a good idea. 1) "Deprecating" an EAPI can mean breakage ---
> see my next point. 2) To tie the deprecation of the older EAPI to the
> introduction of a newer one can delay the introduction of the newer
> one and possibly needed features. You will connect the question of
> "are we ready to deprecate X" with the question "we need to introduce
> Y for needed features a, b and c."

It is hard to grasp for me for when features from a newer EAPI would
delay the migration, do you have an example?

> The statement "Deprecating an EAPI can mean breakage" depends on what
> we mean by "deprecating."  I'm assuming here we mean something like
> repoman won't allow commits at EAPI=1,2,3 but that ebuilds in the
> tree at those EAPI's will continue working.  Eg. dosed which was
> deprecated in the EAPI 3 to 4 jump.

Good point, we should probably split this up in multiple phases:

 1) Repoman warns about deprecation of ebuilds with older EAPI.

 2) Repoman bails out on the addition of _new_ ebuilds with older EAPI.

 3) Repoman bails out on changes to _existing_ ebuilds with older EAPI.

As a side note, we'll need to implement VCS diff support in repoman to
check for this; as currently you can only check based the ebuilds.
Nevertheless a hack is possible, but I think we should avoid that...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/02/14 08:46 AM, Patrick Lauer wrote:
> On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
>> The statement "Deprecating an EAPI can mean breakage" depends on
>> what we mean by "deprecating."  I'm assuming here we mean
>> something like repoman won't allow commits at EAPI=1,2,3 but that
>> ebuilds in the tree at those EAPI's will continue working.  Eg.
>> dosed which was deprecated in the EAPI 3 to 4 jump.
> 
> Right now EAPI 1 and 2 are deprecated, which means repoman prints
> some warnings that get ignored and nothing happens.

Back when these were deprecated, the general consensus was that we
shouldn't change (especially stable) ebuilds in the tree and just
upgrade when we revbump or version bump.

Is this still true?  If so, I'm wondering how many of those older-EAPI
ebuilds are just plain old...


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlL44T8ACgkQ2ugaI38ACPCl1gEAqQYhWVUPjZu05NNAhkhuy36o
jlWfu0lJc6irf5Q2vhkA/0NGS29ceLdGjqLbTa8fYPNlQ/4sntpC04tIMuPI4Obm
=xnk2
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 14:24:39 +0100
Dirkjan Ochtman  wrote:

> On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman 
> wrote:
> > Apart from that, they however sit in the way of deprecating support
> > for that EAPI; at one point it becomes tedious to have to support
> > 10 EAPIs in our code (eg. Portage), hence we should aim to
> > deprecate versions of a few years old. Keeping old stuff around can
> > take its toll...
> 
> Sure, but Patrick was explicitly talking about a burden on developers,
> not a burden on package manager implementers.

Well, that package maintainers are called developers on Gentoo isn't
helping the interpretation here; regardless of how one defines those,
both maintainers and PM implementers have to be taken into account here.

From quick thoughts the latter are a bit more affected than the former,
but perhaps Patrick can highlight what he sees as a burden.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 8:46 AM, Patrick Lauer  wrote:
> I think it's safe to deprecate the antepenultimate EAPI, and then do the
> banning on a more delayed and controlled basis.

Yeah, I don't think we need to overly debate deprecation, other than
in corner cases like the toolchain (just that minor thing...).

I guess to turn things around, does anybody strongly object to the
council banning an EAPI or two?

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Patrick Lauer]

On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
> The statement "Deprecating an EAPI can mean breakage" depends on what we
> mean by "deprecating."  I'm assuming here we mean something like repoman
> won't allow commits at EAPI=1,2,3 but that ebuilds in the tree at those
> EAPI's will continue working.  Eg. dosed which was deprecated in the
> EAPI 3 to 4 jump.

Right now EAPI 1 and 2 are deprecated, which means repoman prints some
warnings that get ignored and nothing happens.

Going from the current state I would distinguish between deprecated
(=unwanted, but tolerated) and banned (not tolerated)

> 
> I think we should look at the question of deprecating EAPI's on and ad
> hoc basis with discussion on the list and a vote in the council.

I think it's safe to deprecate the antepenultimate EAPI, and then do the
banning on a more delayed and controlled basis.

Patrick

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Patrick Lauer]

On 02/10/2014 09:34 PM, Rich Freeman wrote:
> On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer  wrote:
>> Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
> 
> Does "adding" in this case include revbumps?

By the design of our repo structure and repoman, yes.

(I don't see a clean way around that)

>> More than two supported EAPIs is an unneeded burden on developers.
> 
> Is this really a generally held belief? 
Not a belief but experience - I find it really hard to remember all the
corner cases with 6 different flavours (plus eclasses in multiple
revisions, etc. etc.)

Most stuff is "similar enough" to cause funny bugs (like src_prepare not
working, sigh :D )

For me it makes sense to homogenize things so accidental mistakes become
more rare.

Patrick

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer  wrote:
> Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)

Does "adding" in this case include revbumps?

> More than two supported EAPIs is an unneeded burden on developers.

Is this really a generally held belief?  I don't find it a burden that
ebuilds in the tree may use various EAPIs.  I could see how they make
scripted mass-updates to ebuilds more difficult, though I'm not sure
how much of an issue this is in practice.

I could also see how supporting many EAPIs could be a burden on
package managers, but if that is a concern I'd be interested in
hearing from these maintainers.

My sense is that deprecating probably makes sense, but banning should
only be done if in reaction to a particular problem.  Repoman warnings
call attention to the issue so that the maintainer is aware and can
take the appropriate action, but without restricting their actions.

Now, if people are actually impacted by all the EAPIs I don't mind
pushing harder to get rid of some.

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Dirkjan Ochtman]

On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman  wrote:
> Apart from that, they however sit in the way of deprecating support for
> that EAPI; at one point it becomes tedious to have to support 10 EAPIs
> in our code (eg. Portage), hence we should aim to deprecate versions of
> a few years old. Keeping old stuff around can take its toll...

Sure, but Patrick was explicitly talking about a burden on developers,
not a burden on package manager implementers.

Cheers,

Dirkjan

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Anthony G. Basile]

On 02/10/2014 07:43 AM, Patrick Lauer wrote:

EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree
(EAPI 6, most likely)


I am concerned about making this a "rule".  While I think its okay for 
the 4/5/6 move, I'm not sure if it will always be a good idea. 1) 
"Deprecating" an EAPI can mean breakage --- see my next point. 2) To tie 
the deprecation of the older EAPI to the introduction of a newer one can 
delay the introduction of the newer one and possibly needed features.  
You will connect the question of "are we ready to deprecate X" with the 
question "we need to introduce Y for needed features a, b and c."


The statement "Deprecating an EAPI can mean breakage" depends on what we 
mean by "deprecating."  I'm assuming here we mean something like repoman 
won't allow commits at EAPI=1,2,3 but that ebuilds in the tree at those 
EAPI's will continue working.  Eg. dosed which was deprecated in the 
EAPI 3 to 4 jump.


I think we should look at the question of deprecating EAPI's on and ad 
hoc basis with discussion on the list and a vote in the council.


--Tony




Please no bikeshedding,


It should be red.






--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 14:03:49 +0100
Dirkjan Ochtman  wrote:

> On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer 
> wrote:
> > The daily updated stats [2] show a slow general trend down.
> > There's historical data (well, just a few days right now at [3]
> 
> What are you looking at here? .ebuild files in the tree? Or latest
> version per-package?

The same as the repoman warnings do, the .ebuild files; to confirm this
`grep -r --include='*.ebuild'
'^\w*EAPI=\(['"'"'"]1['"'"'"]\|1\)' /usr/portage/ | wc -l` yields 361.

> Old EAPI versions are obviously only a burden for developers if there
> are actually developers looking at those packages/versions/ebuilds...

Maintainership over a package would imply that you also maintain all of
its versions, unless you restrict yourself (but then the rest goes m-n);
they don't necessarily sit in the way for a maintainer, however, there's
still the possibility for people to use them as well as that they cause
bugs that stay around and act as noise. But there's something else:

Apart from that, they however sit in the way of deprecating support for
that EAPI; at one point it becomes tedious to have to support 10 EAPIs
in our code (eg. Portage), hence we should aim to deprecate versions of
a few years old. Keeping old stuff around can take its toll...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Dirkjan Ochtman]

On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer  wrote:
> The daily updated stats [2] show a slow general trend down.
> There's historical data (well, just a few days right now at [3]

What are you looking at here? .ebuild files in the tree? Or latest
version per-package?

Old EAPI versions are obviously only a burden for developers if there
are actually developers looking at those packages/versions/ebuilds...

Cheers,

Dirkjan

Re: [gentoo-dev] gentoo-x86 and git

[Tom Wijsman]

On Mon, 10 Feb 2014 20:33:27 +0800
Patrick Lauer  wrote:

> and it'd be really useful to have the work-in-progress converted repo
> online so that people can experiment with it.

+1; have seen this come up a few times, would love to experiment some
statistics over it myself to see if anything interesting comes out.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[gentoo-dev] [RFC] Tightening EAPI rules

[Patrick Lauer]

As previously discussed I would like to suggest that the number of
tolerated EAPIs be reduced. There's been some discussion
over the last 2+ years, with a weak consensus towards deprecating
some EAPIs. What, when and how still isn't decided.
So let's add some data so we have a better idea:

EAPI Statistics:

The daily updated stats [2] show a slow general trend down.
There's historical data (well, just a few days right now at [3]

The current sum of all ebuilds in tree adds up to ~10% EAPI 1+2
EAPI0 is still surprisingly big around ~15%
EAPI3 is about as big as EAPI2 at around ~7%

According to [1] EAPI 1 and 2 are deprecated.
At the time EAPI 0 was in limbo as toolchain required it
(What's the current status of toolchain on that?)

I suggest the following change:

[ EAPI 0 depends on toolchain's acceptance.
Should toolchain agree then adding EAPI0 ebuilds becomes forbidden]
Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
EAPI 3 becomes deprecated (like 1 and 2 are now)
Adding EAPI 3 ebuilds is forbidden in now +3 months

EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree
(EAPI 6, most likely)

EAPI 5 is the recommended default.


Rationale:
More than two supported EAPIs is an unneeded burden on developers.
Thus 4 will be deprecated when post-5 becomes added.

There's no immediate need to forbid the antepenultimate EAPI immediately.

The goal of this upgrade policy is that we can accelerate the expiration
of old EAPIs - EAPI 2 happened
at some point in 2008, I think (or 2009?) and we still carry
five-year-old cruft around.

Given the percentages -

EAPI 1 can be "cleaned out" by a single motivated individual. It's
almost gone.

EAPI 2 and 3 will take a few months at least, even if there's a
coordinated effort to migrate.
EAPI 0 is as big as 2 and 3 together, and depends on toolchain herd's
actions.
It'll still be around for a looong time. (Given the current rate of
change, plus repoman support, plus people actively working on pruning
it, I would assume it'll take at least a year, more likely two)

In other words, even if we go for the "fastest" option you won't see any
revolutionary change :)

Please no bikeshedding,

Patrick


[1] https://www.gentoo.org/proj/en/council/meeting-logs/20130409.txt
[2] http://packages.gentooexperimental.org/eapi-stats.txt
[3] http://packages.gentooexperimental.org/eapi-history/

[gentoo-dev] gentoo-x86 and git

[Patrick Lauer]

Ahoi,

I've been looking for a clean git-converted gentoo-x86 repo for ... well
... mostly data mining as cvs / anoncvs.g.o is too slow for some things.

This has been needlessly challenging, which confuses me a bit.

First, a little complaint:

There used to be some data at git-exp.overlays.gentoo.org, but that
machine has vanished. Ok, stuff happens, but that's not motivating.

Anoncvs.g.o is bouncing up and down a lot, so just getting the raw cvs
repo to do a local conversion is somewhere between needlessly hard and
impossible.

The gentoo-scm mailinglist has mostly fallen asleep, but even the stuff
discussed there doesn't seem to exist in a public repo that can be found
without telepathy skills.

So ... well ... if it's that hard to just find out the state of the last
experiments there won't be much contribution.

There is a git repository at https://bitbucket.org/lmnd/gentoo-x86 - but
(1) it has truncated history and (2) it diverges by >1500 files from
gentoo-x86 for the last week. So that's mostly useless for data mining.
(I haven't tried figuring out how it diverges, but raw ebuild count is
+1600 for "yesterday", so that's baad)

I'd appreciate it if people that worked on the conversion would point me
at the scripts and documentation they used; I'd appreciate a proper
'official' repo to collect such things; and it'd be really useful to
have the work-in-progress converted repo online so that people can
experiment with it.

(If anyone needs webspace or similar for that, well, I run lots of cruft
anyways, so another annoying thing won't matter ...)

Thanks for your support,

Patrick

P.S. If anyone feels an overwhelming urge to point out the irony ...
don't ;)

Re: [gentoo-dev] Thank you

[Ultrabug]

On 02/06/2014 07:30 AM, Canek Peláez Valdés wrote:

Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so
you can go on your daily business if you don't want to read the rest
of it. No biggie.

Thank you for all the work you guys do and have done.
Thank you for not penalize progress.
Thank you for not being so rigid.
Thank you for keeping the distribution moving and evolving.
And finally, just thank you.



Thank you for your email mate, it's great to read such a positive one :)


 From a proud Gentoo+systemd+GNOME 3 user, thank you.

Regards.



Kindly