[gentoo-dev] Removing a blocker from a stable package

[gentoo-dev] Removing a blocker from a stable package

[Michael Orlitzky]

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?

Re: [gentoo-dev] Removing a blocker from a stable package

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

(d)

Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

On 13 October 2014 17:58, Michael Orlitzky <mjo@gentoo.org> 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?
>
>

[-- Attachment #2: Type: text/html, Size: 1917 bytes --]

Re: [gentoo-dev] Removing a blocker from a stable package

[Anthony G. Basile]

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.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Removing a blocker from a stable package

[Ralph Sennhauser]

On Mon, 13 Oct 2014 14:02:55 -0400
"Anthony G. Basile" <blueness@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.

Re: [gentoo-dev] Removing a blocker from a stable package

[Mike Gilbert]

On Mon, Oct 13, 2014 at 2:20 PM, Ralph Sennhauser <sera@gentoo.org> wrote:
> On Mon, 13 Oct 2014 14:02:55 -0400
> "Anthony G. Basile" <blueness@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.

Re: [gentoo-dev] Removing a blocker from a stable package

[Michael Orlitzky]

On 10/13/2014 02:41 PM, Mike Gilbert wrote:
> 
> 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.
> 

Given that (d) didn't require me to do anything else, I just went ahead
and removed app-doc/djbdns-man. Repoman doesn't even warn. Huh.

Re: [gentoo-dev] Removing a blocker from a stable package

[Anthony G. Basile]

On 10/14/14 20:25, Michael Orlitzky wrote:
> On 10/13/2014 02:41 PM, Mike Gilbert wrote:
>> 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.
>>
> Given that (d) didn't require me to do anything else, I just went ahead
> and removed app-doc/djbdns-man. Repoman doesn't even warn. Huh.
>
>
>
I tested after the last round of emails and found the same.  Let us know 
if something else complains.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Removing a blocker from a stable package

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

that's intended. repoman warns for missing *needed* dependencies, but won't
bother for unknown blockers exactly for cases like this.

Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

On 15 October 2014 01:25, Michael Orlitzky <mjo@gentoo.org> wrote:

> On 10/13/2014 02:41 PM, Mike Gilbert wrote:
> >
> > 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.
> >
>
> Given that (d) didn't require me to do anything else, I just went ahead
> and removed app-doc/djbdns-man. Repoman doesn't even warn. Huh.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1199 bytes --]