Re: s/getmail/getmail6 before freeze (package superseding)

[Greg Troxel <gdt%lexort.com@localhost>]

"Jean-Yves Migeon (NetBSD)" <jym%helkyn.org@localhost> writes:

> I am looking for guidance, pkgsrc guide is not straightforward in
> these cases.

indeed, a lot of this is evolved discussion beyond the guide.


First, I'll say that just before branch is the time everybody tries to
make chagnes like this, and it's the wrong time.  Adding time pressure
isn't helpful, and as Benny said, there's nothing urgent about this.
People can choose 5 or 6 now, and if they want 6 they are running it.  I
see no reason to do anything now instead of early October.

> What we have:
> - mail/getmail, which is -5. Long unmaintained, requires python 2, but
>   remained used for a long time due to blocking bugs that prevented
>   its natural switch to -6 years ago.
> - mail/getmail6, which is a way of getting getmail6 on the system, for
>   those that had OSes were it somewhat works (by luck), or testing.
>
> FWIW both can be installed alongside. But to me the installation looks
> unfortunate, and error-prone for those that want a clear update path:
>
> (v5) mail/getmail/PLIST  => bin/getmail5
> (v6) mail/getmail6/PLIST => bin/getmail

Generally when we have two versions of something (not python itself),
they install the same binary and you can install one or the other.  I
see mail/getmail (5) installing getmail5 as a bug, unless the upstream
norm is to call the binary by that name.

>>    When we have a reason to have multiple packages, we stay at versioned
>>    names for a while, until we're sure we don't need to go back.  Needing
>>    multiple versions is a sign of an unhealthy upstream (or the larger
>>    community), but that's normal.  Perhaps this upstream was unhealthy
>>    and there's a new healthy upstream and this situation can reasonably
>>    be expected to continue.
>
> We can live with a mail/getmail5 and mail/getmail6. I suggest having
> mail/getmail "aliased" to mail/getmail6 though (considering the above)

There is pkg_alternatives, but I don't see that as helpful here.

The real question is how many people are using getmail5, and how much
trouble is it for them.  Moving mail/getmail to mail/getmail5 is good in
that it avoids people thinking mail/getmail is the standard approach.
It's bad in that people have to pkg_delete/pkg_add, but really that's easy.

>>    This seems like a removal proposal (to drop getmail5), and those
>>    belong on pkgsrc-users title as such.
>
> There is no mail/getmail5 package (for now).

I know, but names aside we have a 5 package and a 6 package.  We have
both because when 6 was added, people thought it was somehow not ok for
everybody to just update to 6.  Most packages, when upstream has a
release, we just update because nobody wants to run the old one.  This
isn't like that, as I read the discussion.

> It is more about moving mail/getmail to -6, and considering the above
> PLIST extract, how the transition can be done without too much hiccup.

If there aren't that many users, and they have to remove/add and change
a path in a config file or script, it's really not that big a deal.

>>    It's not clear to me if anybody actually wants to run getmail5.
>> Part
>>    of the removal proposal would include an argument that there aren't
>>    any users, or that the pain of maintenance (which seems near zero)
>>    outweighs the # users.
>
> Considering what other OSes have done, either people moved away to
> getmail6 or another solution (imapsync being one).
>
> pkgsrc remains an exception as it can provide both -5 and -6 at the
> same time with python 2 and 3, which is quite a feat by itself if you
> ask me.

It is, but does any actual person want to have them both installed?

Do you believe that there is anybody out there, such that getmail5 would
be useful to them, while getmail(6) wouldn't work?

My suggestion is to float a removal proposal on pkgsrc-users, and if
after a while we believe nobody cares, then basically drop 5 and move
getmail6 to getmail, as long as you can say you expect that over the
next 3-5 years the odds of the need to have two versions of getmail in
pkgsrc is close to zero.  (Upgrading 6 to 7 is fine; needing 6 and 7
both is not ok for an unversioned getmail.)

If the odds of needing two are not basically zero, then keep getmail6
and rm 5.

(And thanks for fixing DESCR.  To me, helping people who wonder about
which package they want is the most important thing.)