On Mon, Sep 15, 2014 at 10:46:43AM +0200, Natanael Copa wrote:
> On Sat, 13 Sep 2014 13:33:17 -0700
> Isaac Dunham <ibid.ag_at_gmail.com> wrote:
> > I'm inclined to think that in the short term, heirloom-mailx would be
> > a significant improvement over our current main/mailx.
> > What I'd like to do is add testing/heirloom-mailx providing mailx;
> > I have a preliminary aport without the provides part.
> > In the future, upgrading to s-nail seems like a logical path; but
> > I think that using s-nail now might be hasty.
> The upstream tarball is named mailx so i think you can just call it
> testing/mailx and we simply purge unmaintained/mailx.
> Thank you very much for following this up!
I think you're getting packages a little mixed up due to all the
occurences of mailx.
There are two preexisting packages:
mailx-support is the "lockspool" utility from OpenBSD, which should
probably be used whenever mbox-format spools are used.
If it were renamed to lockspool, that would be more informative.
main/mailx is in main, so I don't want to purge it just yet.
But it would be more accurate to rename it to main/mail
Now, a note: If heirloom-mailx gets renamed to mailx, it will need one
I'm using the package name to rename mailx.1 so it doesn't conflict with
In my experiene, the magic that the fts APKBUILD uses to try to avoid
intalling fts-doc along with man-pages doesn't work, so I'd rather not
Received on Mon Sep 15 2014 - 07:37:29 GMT