reassign 1109072 src:alpine
found 1109072 2.26+dfsg-3
thanks

On Thu, Jul 10, 2025 at 10:08:01PM +0000, Lloyd wrote:
> > But mlock is compiled as part of the alpine package, under the name
> > alpine-mlock.
> 
> I missed this due to the renaming of the binary, and thus assumed it wasn't 
> included. It could be the alpine package I examined was the older (unpatched) 
> version.
> 
> > Do you miss mlock because you are still using it,
> > or only because you believed alpine still needed it?
> 
> The latter.
> 
> > If it's the second, I think this bug could be closed. If it's
> > the first, I think mlock as a standalone package is very unlikely
> > to come back, because no other package is using it.
> 
> Am I wrong for thinking there should have been an apt-listchanges NEWS 
> bulletin about this?

It depends on where we put the threshold for such kind of things (see below).

> While I agree there is no bug, maybe there is a bug in the
> documentation? If two packages are being merged, the change should
> have been publicized better unless I'm overlooking something. I can't
> be the only one that will have this concern post-upgrade.

I think that's what the changelog is for:

alpine (2.26+dfsg-3) unstable; urgency=medium

  [ Santiago Vila ]
  * Add debian/salsa-ci.yml.
  * Add patch to build with gettext 0.23.x.
  * Build with --max-parallel=1. Closes: #1089250.
  * Build and use alpine-mlock, drop dependency on mlock. Closes: #1091777.

  [ Unit 193 ]
  * Update Standards-Version to 4.7.2.
    
 -- Unit 193 <unit...@debian.org>  Tue, 01 Apr 2025 02:54:29 -0400
     
In my opinion, warning the user about this via NEWS would be
unnecessary, because alpine works the same before and after the change
and no action from the end user is required at all. My own policy for
NEWS is to use it when it's really important that the user reads it.

> FWIW I did due diligence before opening this bug, somehow I missed
> the new binary when running strings on alpine. Was the renaming to
> avert any package conflict?

Yes. Keeping mlock would involve adding extra conflicts/replaces
for no particular gain. The alpine program will work the same,
so this was the most simple way to implement the feature.

But I'm not the alpine maintainer, I just helped to deprecate mlock
(which is why this bug drew my attention), so I will leave the
alpine maintainers to handle this bug as they see it fits.

(I'm adding them to Cc and reassigning the bug).


BTW: sending a gpg-encrypted copy for a message which is also
sent to 1109...@bugs.debian.org and publically archived here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109072

is a little bit misleading. If you can and it's possible, please find
the way to tell protonmail not to send me encrypted emails related
with the Debian bug system.

Thanks.

Reply via email to