| 1 |
I've got two obsolete packages masked currently: app-text/unix2dos and |
| 2 |
app-doc/djbdns-man. Both of them block other stable packages, |
| 3 |
app-text/dos2unix and net-dns/djbdns respectively. |
| 4 |
|
| 5 |
Fortunately, both of them have had version/revision bumps since the |
| 6 |
blocker so we can remove the blocker from the newer ebuild and then |
| 7 |
stabilize that, at which point there's no problem. But I wonder, what |
| 8 |
would be the best way to handle the situation if no version/revision |
| 9 |
bump had occurred? |
| 10 |
|
| 11 |
In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. In |
| 12 |
-r29, I have, |
| 13 |
|
| 14 |
KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" |
| 15 |
DEPEND="!app-doc/djbdns-man" |
| 16 |
|
| 17 |
and app-doc/djbdns-man is now hard masked. Suppose I remove djbdns-man |
| 18 |
from the tree -- what do I do about the blocker? I see a couple of options: |
| 19 |
|
| 20 |
a) Edit the stable ebuild with ones fingers crossed |
| 21 |
|
| 22 |
b) Do a revbump and wait it out |
| 23 |
|
| 24 |
c) Do a revbump and file a stablereq immediately |
| 25 |
|
| 26 |
d) Do nothing, will repoman tolerate that? |
| 27 |
|
| 28 |
|
| 29 |
(b) is obviously safest, but (c) seems reasonable as well all things |
| 30 |
considered. Will the answer change when portage drops dynamic deps? |
Archives