| 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----- |
Archives