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.
