On Mon, Oct 13, 2014 at 2:20 PM, Ralph Sennhauser <s...@gentoo.org> wrote: > On Mon, 13 Oct 2014 14:02:55 -0400 > "Anthony G. Basile" <bluen...@gentoo.org> wrote: > >> On 10/13/14 12:58, Michael Orlitzky wrote: >> > I've got two obsolete packages masked currently: app-text/unix2dos >> > and app-doc/djbdns-man. Both of them block other stable packages, >> > app-text/dos2unix and net-dns/djbdns respectively. >> > >> > Fortunately, both of them have had version/revision bumps since the >> > blocker so we can remove the blocker from the newer ebuild and then >> > stabilize that, at which point there's no problem. But I wonder, >> > what would be the best way to handle the situation if no >> > version/revision bump had occurred? >> > >> > In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. >> > In -r29, I have, >> > >> > KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" >> > DEPEND="!app-doc/djbdns-man" >> > >> > and app-doc/djbdns-man is now hard masked. Suppose I remove >> > djbdns-man from the tree -- what do I do about the blocker? I see a >> > couple of options: >> > >> > a) Edit the stable ebuild with ones fingers crossed >> > >> > b) Do a revbump and wait it out >> > >> > c) Do a revbump and file a stablereq immediately >> > >> > d) Do nothing, will repoman tolerate that? >> > >> > >> > (b) is obviously safest, but (c) seems reasonable as well all things >> > considered. Will the answer change when portage drops dynamic deps? >> > >> >> You might be okay with rev bumping then then stabilizing yourself on >> the arches since the package has been already tested on them. The >> rev bump doesn't change any files on the system but just gets past >> the blocker. I don't want to speak for all arch teams, but I would be >> okay with that on the arches I take care of: arm, ppc, ppc64. In >> other words, go with C and do the stablereq yourself. >> > > The only right answer is d), carrying the block over to future versions > for some time might even be appropriate. >
I agree with Diego and Ralph: Go with d. repoman will generate a warning (not an error) about a dependency which does not exist, but this is safe to ignore.
