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

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



On Sun, May 03, 2020 at 12:58:19PM +0300, Sergei Golovan wrote:
> > 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.

ACK.
Though it still means that indeed you had to do something in erlang as
well ;)

> > 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).

I see.

> 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.

Alright, then I recommend this:
    reassign 958841 src:erlang 1:22.3.2+dfsg-1
    clone 958841 -1
    reassign -1 src:elixir-lang 1.9.1.dfsg-1.3
    retitle -1 elixir-lang: incompatible with erlang 22
    # consider also leaving a longer message somewhere…?
    close 958841 1:22.3.3+dfsg-1

Doing that should live a RC bug in elixir-lang, and cause its autorm in
a while, and leave erlang where it is, letting it migrate to testing as
soon as elixir-lang is out.  The rm from testing of elixir-lang could be
expedited if nothing happens.

> > 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.

ACK, if really that package is unmaintained it's probably best to not do
anything even if a simple binNMU was enough.  Or we could just try it
and wait till the next breakage before removing elixir-lang from
testing.

I'm not sure I'd call a package "unmaintained" when the last maintainer
upload was last September, so perhaps I'd still try to give it another
chance by binNMUing it.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
More about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Attachment: signature.asc
Description: PGP signature


Reply to: