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

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

TL;DR

To sum up:
- leave mail/getmail as-is for this quarter;
- update mail/getmail6 to latest revision (6.19.10) as it contains all 
our patches upstream;
- update DESCR for mail/getmail to make it clear that it is sunsetting 
and mail/getmail6 shall be considered instead.

After freeze:
- ping pkgsrc-users about mail/getmail becoming mail/getmail5 and that 
getmail6 is the new default;
- "rename" mail/getmail to mail/getmail5

Acceptable?


Le 31/08/2025 à 01:34, Greg Troxel a écrit :
> "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.

Not pressing.

It would be one less package that forces a python2 install around 
considering that there is a working python 3 alternative now.

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

Upstream norm is indeed "getmail".

The -6 fork was seen as hostile/unfriendly to the getmail5 project and 
it seems that the name "getmail6" sticked to distinguish both.

Sadly getmail5 never got patched to support python 3, and I suppose can 
be considered in the same state as python 2. It progressively 
"disappeared" from mainstream pkg managers, and getmail6 became the 
"new" getmail. This is only obvious to pkgsrc-users, as both projects 
can live alongside without conflict. Others were force-switched.

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

IMHO pkgsrc is the only remaining mainstream pkg manager that provides a 
straightforward way to get getmail5. python2 is disappearing everywhere 
else and with it getmail5.

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

Correct

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

ack
> > 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?
Presently: no point with the latest revision (v6.19.10).

Before yes: I could provide both and do some A/B testing. getmail is 
used behind the curtain to fetch mails from different ISP mailboxes many 
of my users accumulated over time. Alas when it crashed/deadlocked I 
could revert to getmail5 for them which was straightforward with pkgsrc 
+ timeout(1).

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

np, thanks for the guidance here (:

--
jym@