1 |
Am 09.12.2013 16:44, schrieb Brian Dolbec: |
2 |
> On Mon, 2013-12-09 at 14:56 +0100, Sebastian Luther wrote: |
3 |
>> Hi all, |
4 |
>> |
5 |
>> I'd like to release a new portage version. You may find the list |
6 |
>> of fixed bugs on the tracker [1] (those not marked as fixed). |
7 |
>> |
8 |
>> Most notable are the slot operator related fixes and the fix for |
9 |
>> binary packages with respect to use dependencies on USE_EXPAND |
10 |
>> values. |
11 |
>> |
12 |
>> I don't think there's anything that should go into the NEWS |
13 |
>> file. |
14 |
>> |
15 |
>> Any objections? |
16 |
>> |
17 |
>> |
18 |
>> What is then needed is someone to create the tarball using |
19 |
>> mkrelease.sh and upload it somewhere. |
20 |
>> |
21 |
>> The ebuild needs an updated SRC_URI. |
22 |
>> |
23 |
>> Any Volunteers? |
24 |
>> |
25 |
>> |
26 |
>> [1] https://bugs.gentoo.org/484436 |
27 |
>> |
28 |
> |
29 |
> Yeah, we also need to update the ebuild. 2.2.7 was still using the |
30 |
> now deprecated EAPI 2 which was getting the attention from the |
31 |
> stabilizing devs. I think it is time to update the ebuild eapi. |
32 |
> We can always keep 2.2.7 around for an upgrade path from older |
33 |
> eapi's. |
34 |
|
35 |
I haven't looked at the upgrade path for quite a while, but it was |
36 |
usually a pain when portage changed its EAPI or python deps. |
37 |
|
38 |
While it's true that leaving old ebuilds available helps with that, |
39 |
it's still annoying. So if we do this, we should have a real good reason. |
40 |
|
41 |
The council voted that EAPI 1 and 2 are discouraged. I'd argue that |
42 |
minimizing upgrade hassle is more worth than not using a discouraged EAPI. |
43 |
|
44 |
To summarize: leave it as is. |
45 |
|
46 |
> |
47 |
> Mike, what about Sebastian's last patch about the /var/run and |
48 |
> compny. The email I fail to find at the moment. I know there was |
49 |
> some additional comments on the bug about /var/lib and one other |
50 |
> directory being excluded. |
51 |
> |