Bug#957230: Bug#966370: bsdmainutils: 12.1.3 removal of lorder breaks rdeps
On 29 Jul 2020, at 09:04, Michael Meskes <meskes@debian.org> wrote:
>
> On Mon, Jul 27, 2020 at 03:01:31PM +0100, Jessica Clarke wrote:
>> Package: bsdmainutils
>> Version: 12.1.3
>> Severity: serious
>> Control: affects -1 src:freebsd-buildutils src:freebsd-glue src:freebsd-libs
>>
>> Hi,
>> The removal of lorder in 12.1.3 causes various freebsd-* packages to
>> FTBFS which are now scheduled for autoremoval from testing. Please
>> restore this shell script; it's not deprecated, it's still widely used
>> by the BSDs and maintained in at least FreeBSD.
>
> I'm surprised it is actually used as it was pointed out to me that the script
> has been non-functional for quite a while.
I do recall having an issue with it at one point a few years back and
meaning to submit a patch to bsdmainutils to fix it, but resolved it
one way or another without that, though can't find any evidence of that
nor can I remember what the problem was. But regardless, it was working
well enough for the freebsd-* packages to build fine.
> Anyway, it cannot easily be "restored"
> because the old bsdmainutils package does not exist anymore. All tools except
> ncal and calendar, which are now in their own package, are now build out of
> util-linux. Would it be possible to include lorder.sh in one of the affected
> freebsd packages?
Yeah, it's possible, and that's no doubt what I'll end up doing. But I
really don't appreciate all the breakage that's come about from
bsdmainutils in the past few months. The util-linux handover was
poorly-handled causing all kinds of problems across the archives
(release and ports), and this removal of something, and thus
*deliberately breaking* the package's "API", should have been done more
carefully by checking whether anyone is actually using it (archive-wide
rebuilds like is done for the new GCC versions is the
easy-but-computationally-expensive way to do it). As it stands, I got
hit with a surprise set of RC bugs from the first archive-wide rebuild
after this change landed, and I therefore have to react in a
time-pressured way to fix it lest packages be removed from testing
(though, arguably, testing doesn't matter so much for these given
kfreebsd-* aren't release architectures). This really should have been
found out first, with Severity: important bugs filed a month or more in
advance of making the change, that can then be upgraded to be
release-critical further down the line. So, please, never do a
transition like this again.
Jess
Reply to: