| 1 |
On Wed, 17 Oct 2012 15:00:12 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> On Wed, Oct 17, 2012 at 1:34 PM, Pacho Ramos <pacho@g.o> wrote: |
| 5 |
> > Would be easier to prune old versions if we "force" them to be less |
| 6 |
> > using at least preventing new ebuilds to use them. For example, what is |
| 7 |
> > the advantage for a new ebuild to still rely on old src_compile phase |
| 8 |
> > instead of src_prepare/configure...? |
| 9 |
> |
| 10 |
> It can be bumped by copying it from the ebuild for the previous |
| 11 |
> version, thus introducing no errors. |
| 12 |
|
| 13 |
Yeah, someone could be making a small change (eg. adding a patch that |
| 14 |
requires a revbump) to a package they don't maintain and aren't familiar |
| 15 |
with. Forcing them to port/rewrite the ebuild isn't going to make anyone |
| 16 |
happy. |
| 17 |
|
| 18 |
> I think the whole developers-can't-handle-47-EAPIs thing is a red |
| 19 |
> herring. The fact that there are packages written in Erlang in the |
| 20 |
> tree doesn't cause me any issues even though I haven't had to do any |
| 21 |
> work in Erlang. If I ever wanted to maintain such a package then I'd |
| 22 |
> take the time to learn it as needed. Likewise, if I wanted to |
| 23 |
> maintain a package that used EAPI joe and I really prefer to work in |
| 24 |
> EAPI fred, then I'd revise it at my next convenience. |
| 25 |
|
| 26 |
Well, it's not just about ebuilds you maintain. Think about something |
| 27 |
like the gcc-porting trackers where you have to touch a lot of ebuilds |
| 28 |
across the tree. You really do have to have a working knowledge of the |
| 29 |
differences between EAPIs to do so. My browser bookmark to the EAPI |
| 30 |
cheatsheet is one of the more frequently used as it is. |
| 31 |
|
| 32 |
|
| 33 |
-- |
| 34 |
gcc-porting |
| 35 |
toolchain, wxwidgets we were never more here, expanse getting broader |
| 36 |
@ gentoo.org but bigger boats been done by less water |
Archives