1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 15/04/15 05:27 PM, James Le Cuirot wrote: |
5 |
> On Sat, 11 Apr 2015 12:29:11 +0200 "Andreas K. Huettel" |
6 |
> <dilfridge@g.o> wrote: |
7 |
> |
8 |
>>> I felt the need to write the above because I have seen many |
9 |
>>> instances where devs not familiar with Java packaging have |
10 |
>>> made this mistake. Now I need to ask what to do in the case of |
11 |
>>> ebuilds that have already been marked stable. |
12 |
>>> |
13 |
>>> To bring up a real example, I would like to bump dev-java/jna |
14 |
>>> with a new SLOT for the new version. There are several reverse |
15 |
>>> dependencies, 3 of which do not specify a SLOT, and 2 of these |
16 |
>>> have already been marked stable. Upon giving jna a new SLOT, |
17 |
>>> all these packages would instantly fail to build if jna:0 is |
18 |
>>> not already installed and they would also fail to run if jna:0 |
19 |
>>> gets depcleaned. Simply leaving the stable ebuilds as they are |
20 |
>>> is therefore not an option. My preferred solution would be |
21 |
>>> create a revbump that solely amends (R)DEPEND, leaving the |
22 |
>>> KEYWORDS exactly as they are. This is controversial but what |
23 |
>>> other choice is there? I could delay the jna bump but this |
24 |
>>> would push back this thread of work by a month when I already |
25 |
>>> have a huge backlog. Please do not let bureaucracy get in the |
26 |
>>> way here. |
27 |
>> |
28 |
>> Sounds good to me (as long as repoman agrees :). |
29 |
> |
30 |
> Turns out it doesn't agree. |
31 |
> |
32 |
> RepoMan scours the neighborhood... KEYWORDS.stable [fatal] 1 |
33 |
> dev-embedded/arduino/arduino-1.0.5-r1.ebuild added with stable |
34 |
> keywords: amd64 x86 |
35 |
> |
36 |
> What are my options? Force it? :/ |
37 |
> |
38 |
|
39 |
If you're revbumping to introduce a necessary dependency change for |
40 |
VDB cleanup, and otherwise the package will be unchanged and will |
41 |
still work as it did before, you can force a direct-to-stable commit. |
42 |
|
43 |
-----BEGIN PGP SIGNATURE----- |
44 |
Version: GnuPG v2 |
45 |
|
46 |
iF4EAREIAAYFAlUu2E4ACgkQ2ugaI38ACPCO0QEAucQpdcs+QHXrgcP/+V25Ntns |
47 |
YPz3ytjZGb+265EIEiUA/RvyilyOnRnaZV27QXINPuWARNNccMyOXFCa0SHl6JgT |
48 |
=qG+K |
49 |
-----END PGP SIGNATURE----- |