[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#959505: release.debian.org: Is erlang autoremoval is necessary?



Hi Mattia,

On Sun, May 3, 2020 at 12:11 PM Mattia Rizzolo <mattia@debian.org> wrote:
>
> On Sun, May 03, 2020 at 09:39:51AM +0300, Sergei Golovan wrote:
> > Today, I've got an autoremoval mails for erlang and a whole bunch of related
> > packages because of #958841 (see [1] for details).
> >
> > Is it really necessary to remove erlang and all its reverse dependencies,
> > while it's elixir-lang which is the culprit?
>
> Well, that bug is assigned to *both* erlang and erlang-elixir, and in
> fact, the fix was done in erlang, so it really much looks like an erlang
> bug?

It wasn't really a fix, I just bumped the erlang-pcre virtual package version
exactly to make elixir-lang uninstallable because it's broken.

>
> Now, it seems that wasn't enough, since erlang-elixir still doesn't pass
> its autopkgtest with the new erlang; worse, it makes elixir-lang
> uninstallable.

Elixir-lang (at least its current version in Debian) uses some
unstable interface
in Erlang, so it's sometimes requires to be rebuilt with the new erlang.
As far as I can see now, elixir-lang is basically unmaintained, so nobody
will ask for binNMU (it should be sufficient, but I havent't checked this).

>
> > As far as I can see, removal
> > of all erlang related packages (which includes elixir-lang) should lead to
> > moving them back except for elixir-lang which is now uninstallable.
>
> What do you mean with "moving back"?

After erlang, elixir-lang and many other packages will be removed from
testing, nothing should prevent erlang and other packages to move back again,
because there wouldn't be a problem with them in testing anymore. elixir-lang,
on the other hand remains uninstallable in unstable (which is fine by me, since
it isn't maintained anyway).

>
> > On the other hand, just removing elixir-lang from testing achieves the same
> > outcome without removing/moving back many packages.
>
> The autoremoval is quite confusing (perhaps actually buggy?) when bugs
> are assigned against multiple packages.  In fact, only erlang is being
> autoremoved, elixir-lang is being removed only due to being a rdep of
> erlang.

I see that. May be it's a bug in autoremovals. As for now, erlang
version in testing
isn't buggy, and the bugreport was actually filed against 1:22.3.2+dfsg-1 which
was in unstable at the time of the bugreport.

>
> Please read with more attention the text of the bug:
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958841
> | Due to the nature of this issue, I filed this bug report against
> | both packages. Can you please investigate the situation and reassign the
> | bug to the right package?
> I'm confident that if you reassign this bug to erlang only (and properly
> changing the 'found', 'fixed' and 'done' values), nothing
> would be autoremoved, simply because that bug won't affect erlang in
> testing anymore.

It's not a desirable output here. This means that without some changes
in elixir-lang
new erlang packages will never reach testing. I'm not sure that an unmaintained
package should stall development of its reverse dependencies like that.

>
> Lastly, I recommend you just don't spend too much time on understanding
> the autorm situation, rather just fix whatever is broken and make
> elixir-lang pass the autopkgtest again; the autorm date is more than a
> month away after all.

I would say that binNMU would be sufficient for now, but I wouldn't like to
constantly monitor this elixir-lang situation.

Cheers!
-- 
Sergei Golovan


Reply to: