Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1071222 > unrolled thread

Bug#994275: Reverting breaking changes in debianutils

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#994275: Reverting breaking changes in debianutils Adrian Bunk <bunk@debian.org> - 2021-09-15 00:40 +0200
    Bug#994275: Reverting breaking changes in debianutils Helmut Grohne <helmut@subdivi.de> - 2021-09-15 09:30 +0200
      Bug#994275: Reverting breaking changes in debianutils Adrian Bunk <bunk@debian.org> - 2021-09-15 12:00 +0200
        Bug#994275: Reverting breaking changes in debianutils Helmut Grohne <helmut@subdivi.de> - 2021-09-15 14:20 +0200
    Bug#994275: Reverting breaking changes in debianutils Simon McVittie <smcv@debian.org> - 2021-09-15 13:10 +0200
    Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-09-16 23:40 +0200
    Bug#994275: Reverting breaking changes in debianutils Sean Whitton <spwhitton@spwhitton.name> - 2021-09-17 00:10 +0200
    Bug#994275: Reverting breaking changes in debianutils Sean Whitton <spwhitton@spwhitton.name> - 2021-09-17 00:10 +0200
      Bug#994275: Reverting breaking changes in debianutils Adrian Bunk <bunk@debian.org> - 2021-09-24 08:30 +0200
        Bug#994275: Reverting breaking changes in debianutils Thorsten Glaser <t.glaser@tarent.de> - 2021-09-24 10:20 +0200
        Bug#994275: Reverting breaking changes in debianutils Ansgar <ansgar@43-1.org> - 2021-09-24 10:50 +0200
          Bug#994275: Reverting breaking changes in debianutils Adrian Bunk <bunk@debian.org> - 2021-09-24 14:20 +0200
        Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-09-24 15:00 +0200
    Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-09-25 04:30 +0200
      Bug#994275: Reverting breaking changes in debianutils Simon McVittie <smcv@debian.org> - 2021-09-25 12:40 +0200
        Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-10-04 00:20 +0200
          Bug#994275: Reverting breaking changes in debianutils Simon McVittie <smcv@debian.org> - 2021-10-06 11:40 +0200
            Bug#994275: Reverting breaking changes in debianutils Adrian Bunk <bunk@debian.org> - 2021-10-06 12:40 +0200
            Bug#994275: Reverting breaking changes in debianutils Russ Allbery <rra@debian.org> - 2021-10-06 18:20 +0200
    Bug#994275: Reverting breaking changes in debianutils Simon McVittie <smcv@debian.org> - 2021-10-11 02:00 +0200
    Bug#994275: Reverting breaking changes in debianutils Simon McVittie <smcv@debian.org> - 2021-10-11 02:10 +0200
      Bug#994275: Reverting breaking changes in debianutils Sebastian Ramacher <sramacher@debian.org> - 2021-10-11 10:50 +0200
        Bug#994275: Reverting breaking changes in debianutils Felix Lechner <felix.lechner@lease-up.com> - 2021-10-17 14:40 +0200
    Bug#994275: Draft resolution for reverting changes in debianutils Sean Whitton <spwhitton@spwhitton.name> - 2021-10-13 22:20 +0200
      Bug#994275: Draft resolution for reverting changes in debianutils David Bremner <david@tethera.net> - 2021-10-14 00:40 +0200
        Bug#994275: Draft resolution for reverting changes in debianutils Wookey <wookey@wookware.org> - 2021-10-17 15:40 +0200
        Bug#994275: Draft resolution for reverting changes in debianutils Raphael Hertzog <hertzog@debian.org> - 2021-10-18 11:40 +0200
          Bug#994275: Draft resolution for reverting changes in debianutils Adam Borowski <kilobyte@angband.pl> - 2021-10-18 12:30 +0200
            Bug#994275: Draft resolution for reverting changes in debianutils Christoph Berg <myon@debian.org> - 2021-10-18 12:50 +0200
        Bug#994275: Draft resolution for reverting changes in debianutils Sean Whitton <spwhitton@spwhitton.name> - 2021-10-18 21:00 +0200
          Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-10-24 21:20 +0200
            Bug#994275: Reverting breaking changes in debianutils tito <farmatito@tiscali.it> - 2021-10-26 13:00 +0200
            Bug#994275: Reverting breaking changes in debianutils Wookey <wookey@wookware.org> - 2021-10-26 15:20 +0200
              Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-10-26 21:20 +0200
                Bug#994275: Reverting breaking changes in debianutils Thorsten Glaser <t.glaser@tarent.de> - 2021-10-26 22:00 +0200
                  Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-10-26 22:20 +0200
            Bug#994275: Reverting breaking changes in debianutils Raphael Hertzog <hertzog@debian.org> - 2021-10-29 10:10 +0200
      Bug#994275: Reverting breaking changes in debianutils Clint Adams <clint@debian.org> - 2021-10-16 08:00 +0200
        Bug#994275: Reverting breaking changes in debianutils Thorsten Glaser <t.glaser@tarent.de> - 2021-10-16 18:00 +0200
        Bug#994275: Reverting breaking changes in debianutils James Cloos <cloos@jhcloos.com> - 2021-10-17 12:50 +0200
        Bug#994275: Reverting breaking changes in debianutils Sean Whitton <spwhitton@spwhitton.name> - 2021-10-18 21:00 +0200
    Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Sean Whitton <spwhitton@spwhitton.name> - 2021-10-20 21:40 +0200
      Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Gunnar Wolf <gwolf@debian.org> - 2021-10-21 18:00 +0200
    Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Sean Whitton <spwhitton@spwhitton.name> - 2021-10-20 21:40 +0200
      Bug#994275: Call for votes on "Reverting breaking changes in debianutils" David Bremner <david@tethera.net> - 2021-10-20 22:10 +0200
      Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Christoph Berg <myon@debian.org> - 2021-10-22 20:50 +0200
      Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Elana Hashman <ehashman@debian.org> - 2021-10-22 22:00 +0200
      Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Margarita Manterola <marga@debian.org> - 2021-10-26 19:20 +0200
      Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Niko Tyni <ntyni@debian.org> - 2021-10-26 21:20 +0200
      Bug#994275: Call for votes on "Reverting breaking changes in debianutils" Simon McVittie <smcv@debian.org> - 2021-10-27 19:10 +0200
    Bug#994275: Reverting breaking changes in debianutils Raphael Hertzog <hertzog@debian.org> - 2021-11-02 08:40 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1075135

On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> The release team has so far protected users of testing from the
> problem by blocking testing migration, but this is not a long-term
> solution.

Adrian asked in #994275 for changes in several topics to be reverted:

- which(1) deprecation
  - deprecation warnings on stderr
  - management via alternatives
  - possible future removal
- tempfile(1) removal
- installkernel(8) moving from /sbin to /usr/sbin
- run-parts(8) moving from /bin to /usr/bin

Which of those topics were your reason for adding a "block debianutils"
hint? Are there any of those topics whose resolution you would consider
to be a prerequisite for letting debianutils migrate to testing again?

The hint references #992399, which is related to tempfile(1), but
#992399 has been closed (via a merge with #992396, which was resolved by
debianutils adding a versioned Breaks on x11-common versions that needed
tempfile). Do the release team consider #992399 to have been adequately
resolved, or do you consider debianutils to still have a RC bug?

If debianutils reinstated tempfile(1) in bookworm, and removed it in
testing/unstable after the release of bookworm, would the release team
consider that to be an adequate transitional period?

Thanks,
    smcv

[toc] | [prev] | [next] | [standalone]

#1075164

[Multipart message — attachments visible in raw view] — view raw

Hi Simon

On 2021-10-11 01:01:45 +0100, Simon McVittie wrote:
> On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> > The release team has so far protected users of testing from the
> > problem by blocking testing migration, but this is not a long-term
> > solution.
> 
> Adrian asked in #994275 for changes in several topics to be reverted:
> 
> - which(1) deprecation
>   - deprecation warnings on stderr
>   - management via alternatives
>   - possible future removal
> - tempfile(1) removal
> - installkernel(8) moving from /sbin to /usr/sbin
> - run-parts(8) moving from /bin to /usr/bin
> 
> Which of those topics were your reason for adding a "block debianutils"
> hint? Are there any of those topics whose resolution you would consider
> to be a prerequisite for letting debianutils migrate to testing again?

I don't care about which(1). My reason for blocking debianutils was the
tempfile(1) removal, but I suppose now I would add the last two points
to the list as well - but usrmerge is the topic of another CTTE bug
anyway.

> The hint references #992399, which is related to tempfile(1), but
> #992399 has been closed (via a merge with #992396, which was resolved by
> debianutils adding a versioned Breaks on x11-common versions that needed
> tempfile). Do the release team consider #992399 to have been adequately
> resolved, or do you consider debianutils to still have a RC bug?

I don't consider #992399 to be fixed. I specifically asked for a
coordinated transition for the tempfile removal in that bug. So far I
see no indication that this transition is coordinated in any way. As far
as I can tell, the current strategy is to hope that users of unstable
install a large enough set of packages to discover all the remaining
uses of tempfile in maintainer scripts. See #993621, #994877, #996099
(which I just filed after a grep for tempfile in /var/lib/dpkg/info) for
the latest examples.

I think it would have been easy enough to follow a more systematic
approach by processing the whole archive with piuparts to detect all the
remaining cases.

Additionally, Debian Policy 10.4 and the lintian tag
possibly-insecure-handling-of-tmp-files-in-maintainer-script still
recommend "tempfile or mktemp".

Beyond tempfile(1) in maintainer scripts, random uses of tempfile
are still being reported. See #995583 for the latest example. But also
for this case, I see no coordination.

> If debianutils reinstated tempfile(1) in bookworm, and removed it in
> testing/unstable after the release of bookworm, would the release team
> consider that to be an adequate transitional period?

Helmut has shown how to remove interfaces from the essential set with
e2fsprogs. But I think e2fsprogs was in a much better place when this
was done: the interesting interfaces were moved to util-linux and for
the remaining users of e2fsprogs it was easy enough to add dependencies.
tempfile(1) however is used in maintainer scripts with the potential for
upgrade failures. At least for that case I would expect that all the
users are fixed in release $x and then tempfile could be removed in $x
+ 1.

For all the other uses of tempfile, I'm currently lacking an overview.

Cheers

> 
> Thanks,
>     smcv

-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1076303

Hi,

On Mon, Oct 11, 2021 at 1:45 AM Sebastian Ramacher <sramacher@debian.org> wrote:
>
> the lintian tag
> possibly-insecure-handling-of-tmp-files-in-maintainer-script still
> recommend "tempfile or mktemp".

Lintian's last remaining reference to 'tempfile' was dropped. [1] The
updated tag description is now live on our website. [2]

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian/-/commit/af93172c7a9ef326a68fd337c5089c52b74eb3f5
[2] https://lintian.debian.org/tags/possibly-insecure-handling-of-tmp-files-in-maintainer-script

[toc] | [prev] | [next] | [standalone]

#1075744 — Bug#994275: Draft resolution for reverting changes in debianutils

[Multipart message — attachments visible in raw view] — view raw

Dear all,

We think we might have a consensus on the following resolution text.  We
could be wrong, as the judgement of consensus has been made by just a
few of us.  We agreed in our meeting today that I'll start a vote a week
from today unless a ctte member asks for a delay.  Thus, we expect to
close this bug approximately two weeks from today.

Many thanks to Simon for a previous draft of this text.

~=~=~=~=~

1. Offer advice:

   The debianutils package must continue to provide the which(1) program
   until a compatible utility is available in a package that is at least
   transitively essential in Debian 12.

   For the Debian 12 release, we expect which(1) to be in either an
   Essential package or a transitively Essential package (that is, a
   package that is depended on by an Essential package).

2. Overrule maintainer of debianutils:

   The which(1) program must not print any deprecation warnings.

3. Decline to overrule maintainer regarding use of alternatives:

   If another package takes over responsibility for which(1), then the
   debianutils maintainers and the other package's maintainers should
   coordinate to choose a suitable mechanism, which might be either
   versioned Depends/Breaks/Replaces, dpkg-divert, alternatives or
   something else.

4. Overrule maintainer of debianutils:

   The debianutils package must continue to provide the tempfile(1)
   program until a compatible utility is available in a package that is
   at least transitively essential in Debian 12.

   For the Debian 12 release, we expect tempfile(1) to be in either an
   Essential package or a transitively Essential package.

5. Overrule maintainer of debianutils:

   Programs in debianutils must not be moved to /usr until we have a
   project-wide consensus on going ahead with such a move, and any
   programs that have already been moved must be moved back.  In
   particular, this means debianutils must contain /bin/run-parts and
   /sbin/installkernel for the time being.

~=~=~=~=~

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1075766 — Bug#994275: Draft resolution for reverting changes in debianutils

Sean Whitton <spwhitton@spwhitton.name> writes:

> 1. Offer advice:

>    The debianutils package must continue to provide the which(1) program
>    until a compatible utility is available in a package that is at least
>    transitively essential in Debian 12.

Is it really advice if we say "must"?

> 2. Overrule maintainer of debianutils:
>
>    The which(1) program must not print any deprecation warnings.

I remain to be convinced on this point. If I understand the issue
correctly the problem is with autopkgtests failing because they were not
expecting output on stderr. I don't think people are really entitled to
expect which(1) to never print to stderr. Even when debian-policy
recommended 'which' it apparently recommended redirecting stderr.

I also don't see failures of autopkgtests as directly impacting users in
the same way a failure to build or a failure to install does.

I understand that people find the message annoying, and perhaps not that
useful, but I don't think that rises the level justifying overriding a
maintainer.

[toc] | [prev] | [next] | [standalone]

#1076319 — Bug#994275: Draft resolution for reverting changes in debianutils

[Multipart message — attachments visible in raw view] — view raw

On 2021-10-13 19:37 -0300, David Bremner wrote:
> Sean Whitton <spwhitton@spwhitton.name> writes:

> >    The which(1) program must not print any deprecation warnings.
> 
> I remain to be convinced on this point. If I understand the issue
> correctly the problem is with autopkgtests failing because they were not
> expecting output on stderr.

It's not just that. Builds fail too. tensorflow now FTBFS in unstable
because of this change, and the way bazel deals (or fails to deal)
with it. I gave details further up the thread.

> I understand that people find the message annoying, and perhaps not that
> useful, but I don't think that rises the level justifying overriding a
> maintainer.

I think causing build failures is enough reason to say this. I don't
suppose that mine is the only one. Yes those builds are buggy and
should not do this, and we should make efforts to find out why bazel
(or possibly the build scripts it is operating on) is/are so crappy,
but for now I agree that reverting this is the right thing to do.

We have time to do this transition properly and quietly in the
background, without causing random breakage. A message about a binary
moving from one package to another does not need to be printed on
every usage of that binary. Indeed it is actively unhelpful to do so.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

[toc] | [prev] | [next] | [standalone]

#1076443 — Bug#994275: Draft resolution for reverting changes in debianutils

Hi,

On Wed, 13 Oct 2021, David Bremner wrote:
> >    The which(1) program must not print any deprecation warnings.
> 
> I remain to be convinced on this point. If I understand the issue
> correctly the problem is with autopkgtests failing because they were not
> expecting output on stderr. I don't think people are really entitled to
> expect which(1) to never print to stderr. Even when debian-policy
> recommended 'which' it apparently recommended redirecting stderr.
> 
> I also don't see failures of autopkgtests as directly impacting users in
> the same way a failure to build or a failure to install does.

There have been other reports of failures due to the message on stderr,
autopkgtest is not the only one (wookey mentionned a build failure).

In any case, a message saying that which is deprecated when in fact
`which` will stay around (but maintained in another packages) is not
helpful.

> I understand that people find the message annoying, and perhaps not that
> useful, but I don't think that rises the level justifying overriding a
> maintainer.

I think it does.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

[toc] | [prev] | [next] | [standalone]

#1076446 — Bug#994275: Draft resolution for reverting changes in debianutils

On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote:
> There have been other reports of failures due to the message on stderr,
> autopkgtest is not the only one (wookey mentionned a build failure).
> 
> In any case, a message saying that which is deprecated when in fact
> `which` will stay around (but maintained in another packages) is not
> helpful.

I'm even considering a MBF to go the _other_ way: change all but most
obviously correct uses of `command -v` to `which`.  The former is a footgun
when a shell has extra builtins -- and eg. busybox sh has the world builtin.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#1076451 — Bug#994275: Draft resolution for reverting changes in debianutils

Re: Adam Borowski
> I'm even considering a MBF to go the _other_ way: change all but most
> obviously correct uses of `command -v` to `which`.

Please just don't.

Christoph

[toc] | [prev] | [next] | [standalone]

#1076518 — Bug#994275: Draft resolution for reverting changes in debianutils

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Wed 13 Oct 2021 at 07:37PM -03, David Bremner wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> 1. Offer advice:
>
>>    The debianutils package must continue to provide the which(1) program
>>    until a compatible utility is available in a package that is at least
>>    transitively essential in Debian 12.
>
> Is it really advice if we say "must"?

The point here is just that the maintainer has not dropped which(1) so
it is not the case that we are overruling the maintainer, unlike in the
other points.  Perhaps we could label it as falling under 6.1.1 instead?
That's still distinct from 6.1.4.

>> 2. Overrule maintainer of debianutils:
>>
>>    The which(1) program must not print any deprecation warnings.
>
> I remain to be convinced on this point.

Okay.  Procedurally, what I think we should do here is have two options
other than FD on the ballot, with and without this particular bit of the
resolution.

> If I understand the issue correctly the problem is with autopkgtests
> failing because they were not expecting output on stderr. I don't
> think people are really entitled to expect which(1) to never print to
> stderr. Even when debian-policy recommended 'which' it apparently
> recommended redirecting stderr.
>
> I also don't see failures of autopkgtests as directly impacting users in
> the same way a failure to build or a failure to install does.
>
> I understand that people find the message annoying, and perhaps not that
> useful, but I don't think that rises the level justifying overriding a
> maintainer.

As Raphael has mentioned, it's unlikely that when debianutils' which(1)
has been replaced with one in another essential or transitively
essential package that the new which(1), whether it's the same code or
something else, will print deprecation warnings.  And then it seems odd
to print them for a while and then stop printing them.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1077883

On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote:
> No. You’re conflating “which <cmd>”, which indeed is mostly redundant
> with “command -v”, with “which -a <cmd>”, which is NOT otherwise
> available, and a very useful thing to have, and one which (heh, pun
> not intended) I pretty much expect to exist on a system.

I can think of no reason why anyone would need to run `which -a`
from a maintainer script.  For interactive use, csh (and tcsh)
never had -a for `which`.  The reason that zsh has `which -a` is
because it shares code with `whence -a`, which was taken from
ksh in the '80s.  Of course there's no telling whether it would
have evolved later on if it had been originally csh-compatible.

> I know that feeling… some package maintainers don’t seem to care about
> warnings. But as something in an Essential package I fear it’s up to
> you to ping them, time and time again, until they don’t depend on it
> any more, instead of proactively removing it.

I disagree.  This is not a good system.  This is how you architect an
ultraconservative culture that discourages people from fixing things.

On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote:
> i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
> postint script and its removal started blocking my apt upgrades.  i had
> to copy tempfile over from a virt stuck on an older deb to get around it.
> 
> (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)
> 
> it would be useful to ensure no packages rely on something before
> removing it...

The fix for pv-grub-menu is as follows:

---8<---snip---8<---
diff --git a/update-menu-lst b/update-menu-lst
index f2ca1c7..2e01a39 100755
--- a/update-menu-lst
+++ b/update-menu-lst
@@ -128,7 +128,7 @@ fi
 # Default options to use in a new config file. This will only be used if $menu_file
 # doesn't already exist. Only edit the lines between the two "EOF"s. The others are
 # part of the script.
-newtemplate=$(tempfile)
+newtemplate=$(mktemp)
 cat > "$newtemplate" <<EOF
 # $menu_file_basename - See: grub(8), info grub, update-grub(8)
 #            grub-install(8), grub-floppy(8),
@@ -443,7 +443,7 @@ howmany=$(GetMenuOpt "howmany" "$howmany")
 memtest86=$(GetMenuOpt "memtest86" "$memtest86")
 
 # Generate the menu options we want to insert
-buffer=$(tempfile)
+buffer=$(mktemp)
 echo $start >> $buffer
 echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" >> $buffer
 echo "## by the debian update-grub script except for the default options below" >> $buffer
---8<---snip---8<---

How much effort is involved with that?  I would guess that it is less than
bullying me into adding a `tempfile` as a Debian-specific patch to debianutils
or bullying me into uploading a `tempfile` package that I do not wish to
maintain.

On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote:
> Lintian's last remaining reference to 'tempfile' was dropped. [1] The
> updated tag description is now live on our website. [2]

Thanks.

On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> I think causing build failures is enough reason to say this. I don't
> suppose that mine is the only one. Yes those builds are buggy and
> should not do this, and we should make efforts to find out why bazel
> (or possibly the build scripts it is operating on) is/are so crappy,
> but for now I agree that reverting this is the right thing to do.
> 
> We have time to do this transition properly and quietly in the
> background, without causing random breakage. A message about a binary
> moving from one package to another does not need to be printed on
> every usage of that binary. Indeed it is actively unhelpful to do so.

Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
October, and neither GNU which nor *BSD which nor any other which
alternative is in unstable.  Presumably one of these could have put
a band-aid on your bazel problem, though of course any version of
`which` might output things to stderr for a variety of reasons.

Lots of things broke between buster and bullseye.  Even in stable,
people are struggling with horrible i915 driver bugs.  Would it have
been reasonable to demand that bullseye's kernel be reverted to Linux
4.19 and kept there for 5-10 years until someone figured out the
drm issues?

My DreamPlug's audio device went from being card0 to card1, breaking
everything expecting it to be card0.  Would it have been reasonable
to revert Linux, ALSA userland, systemd/udev, and whichever other
packages until I found the time to figure out what changed and why?

Is the difference that these packages aren't Essential?  Or that the
bug is within the packages themselves instead of a reverse dependency?
Or that it involves a package build instead of ordinary operation?

On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 13 Oct 2021, David Bremner wrote:
> There have been other reports of failures due to the message on stderr,
> autopkgtest is not the only one (wookey mentionned a build failure).

GNU which can output things to stderr.  FreeBSD which can output to stderr.
There is no guarantee that cjwatson which won't output anything else to
stderr.

> In any case, a message saying that which is deprecated when in fact
> `which` will stay around (but maintained in another packages) is not
> helpful.

Tell me, what would be helpful?

On Mon, Oct 18, 2021 at 11:50:32AM -0700, Sean Whitton wrote:
> As Raphael has mentioned, it's unlikely that when debianutils' which(1)
> has been replaced with one in another essential or transitively
> essential package that the new which(1), whether it's the same code or
> something else, will print deprecation warnings.  And then it seems odd
> to print them for a while and then stop printing them.

I find this to be a curious statement.  This implies a contract of
future behavior that does not exist.

[toc] | [prev] | [next] | [standalone]

#1078110

On Sun, 24 Oct 2021 19:08:20 +0000
Clint Adams <clint@debian.org> wrote:

> On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote:
> > No. You’re conflating “which <cmd>”, which indeed is mostly redundant
> > with “command -v”, with “which -a <cmd>”, which is NOT otherwise
> > available, and a very useful thing to have, and one which (heh, pun
> > not intended) I pretty much expect to exist on a system.
> 
> I can think of no reason why anyone would need to run `which -a`
> from a maintainer script.  For interactive use, csh (and tcsh)
> never had -a for `which`.  The reason that zsh has `which -a` is
> because it shares code with `whence -a`, which was taken from
> ksh in the '80s.  Of course there's no telling whether it would
> have evolved later on if it had been originally csh-compatible.
> 
> > I know that feeling… some package maintainers don’t seem to care about
> > warnings. But as something in an Essential package I fear it’s up to
> > you to ping them, time and time again, until they don’t depend on it
> > any more, instead of proactively removing it.
> 
> I disagree.  This is not a good system.  This is how you architect an
> ultraconservative culture that discourages people from fixing things.
> 
> On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote:
> > i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
> > postint script and its removal started blocking my apt upgrades.  i had
> > to copy tempfile over from a virt stuck on an older deb to get around it.
> > 
> > (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)
> > 
> > it would be useful to ensure no packages rely on something before
> > removing it...
> 
> The fix for pv-grub-menu is as follows:
> 
> ---8<---snip---8<---
> diff --git a/update-menu-lst b/update-menu-lst
> index f2ca1c7..2e01a39 100755
> --- a/update-menu-lst
> +++ b/update-menu-lst
> @@ -128,7 +128,7 @@ fi
>  # Default options to use in a new config file. This will only be used if $menu_file
>  # doesn't already exist. Only edit the lines between the two "EOF"s. The others are
>  # part of the script.
> -newtemplate=$(tempfile)
> +newtemplate=$(mktemp)
>  cat > "$newtemplate" <<EOF
>  # $menu_file_basename - See: grub(8), info grub, update-grub(8)
>  #            grub-install(8), grub-floppy(8),
> @@ -443,7 +443,7 @@ howmany=$(GetMenuOpt "howmany" "$howmany")
>  memtest86=$(GetMenuOpt "memtest86" "$memtest86")
>  
>  # Generate the menu options we want to insert
> -buffer=$(tempfile)
> +buffer=$(mktemp)
>  echo $start >> $buffer
>  echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" >> $buffer
>  echo "## by the debian update-grub script except for the default options below" >> $buffer
> ---8<---snip---8<---
> 
> How much effort is involved with that?  I would guess that it is less than
> bullying me into adding a `tempfile` as a Debian-specific patch to debianutils
> or bullying me into uploading a `tempfile` package that I do not wish to
> maintain.
> 
> On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote:
> > Lintian's last remaining reference to 'tempfile' was dropped. [1] The
> > updated tag description is now live on our website. [2]
> 
> Thanks.
> 
> On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> > I think causing build failures is enough reason to say this. I don't
> > suppose that mine is the only one. Yes those builds are buggy and
> > should not do this, and we should make efforts to find out why bazel
> > (or possibly the build scripts it is operating on) is/are so crappy,
> > but for now I agree that reverting this is the right thing to do.
> > 
> > We have time to do this transition properly and quietly in the
> > background, without causing random breakage. A message about a binary
> > moving from one package to another does not need to be printed on
> > every usage of that binary. Indeed it is actively unhelpful to do so.
> 
> Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
> October, and neither GNU which nor *BSD which nor any other which
> alternative is in unstable.  Presumably one of these could have put
> a band-aid on your bazel problem, though of course any version of
> `which` might output things to stderr for a variety of reasons.

Hi,
there is busybox that has which compiled in and is available
in all repos :

$busybox which
BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) multi-call binary.

Usage: which [COMMAND]...

Locate a COMMAND

and It does have command line option -a 

	getopt32(argv, "^" "a" "\0" "-1"/*at least one arg*/);

even if the help says nothing about it.

busybox which -a sh
/home/tito/bin/sh
/bin/sh
 
It is possible to create a single command package if somebody
will maintain it ( e.g busybox-which) like it was done for busybox-syslogd.
tempfile is missing tough.

Hope this helps.

Ciao,
Tito

> Lots of things broke between buster and bullseye.  Even in stable,
> people are struggling with horrible i915 driver bugs.  Would it have
> been reasonable to demand that bullseye's kernel be reverted to Linux
> 4.19 and kept there for 5-10 years until someone figured out the
> drm issues?
> 
> My DreamPlug's audio device went from being card0 to card1, breaking
> everything expecting it to be card0.  Would it have been reasonable
> to revert Linux, ALSA userland, systemd/udev, and whichever other
> packages until I found the time to figure out what changed and why?
> 
> Is the difference that these packages aren't Essential?  Or that the
> bug is within the packages themselves instead of a reverse dependency?
> Or that it involves a package build instead of ordinary operation?
> 
> On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote:
> > Hi,
> > 
> > On Wed, 13 Oct 2021, David Bremner wrote:
> > There have been other reports of failures due to the message on stderr,
> > autopkgtest is not the only one (wookey mentionned a build failure).
> 
> GNU which can output things to stderr.  FreeBSD which can output to stderr.
> There is no guarantee that cjwatson which won't output anything else to
> stderr.
> 
> > In any case, a message saying that which is deprecated when in fact
> > `which` will stay around (but maintained in another packages) is not
> > helpful.
> 
> Tell me, what would be helpful?
> 
> On Mon, Oct 18, 2021 at 11:50:32AM -0700, Sean Whitton wrote:
> > As Raphael has mentioned, it's unlikely that when debianutils' which(1)
> > has been replaced with one in another essential or transitively
> > essential package that the new which(1), whether it's the same code or
> > something else, will print deprecation warnings.  And then it seems odd
> > to print them for a while and then stop printing them.
> 
> I find this to be a curious statement.  This implies a contract of
> future behavior that does not exist.
> 

[toc] | [prev] | [next] | [standalone]

#1078123

[Multipart message — attachments visible in raw view] — view raw

On 2021-10-24 19:08 +0000, Clint Adams wrote:
> On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> > I think causing build failures is enough reason to say this. I don't
> > suppose that mine is the only one. Yes those builds are buggy and
> > should not do this, and we should make efforts to find out why bazel
> > (or possibly the build scripts it is operating on) is/are so crappy,
> > but for now I agree that reverting this is the right thing to do.
> > 
> > We have time to do this transition properly and quietly in the
> > background, without causing random breakage. A message about a binary
> > moving from one package to another does not need to be printed on
> > every usage of that binary. Indeed it is actively unhelpful to do so.
> 
> Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
> October, and neither GNU which nor *BSD which nor any other which
> alternative is in unstable.  Presumably one of these could have put
> a band-aid on your bazel problem, though of course any version of
> `which` might output things to stderr for a variety of reasons.

That package is the band-aid I am currently using, but (because it has
indeed not progressed through NEW yet, which is presumably down to
ftpmaster bandwidth) it's a hassle where I have to make sure it is
made available in the build environment each time.

> Lots of things broke between buster and bullseye.

Most of them broke by accident or for good reasons. You broke this
semi-deliberately, by deciding not to manage a quiet background
transition of the which binary to some other package, but to print
a deprecation message and let other people deal with the fallout. OK,
maybe you expected the change to be harmless, but you didn't revert it
once it became clear that this was not a good way to do the
transition.

IIUC the tech committee have now told you to do it properly, as a
managed transition. Good.

> Is the difference that these packages aren't Essential?

The difference from where I am standing is the attitude of the
maintainer to doing things properly vs causing other people
hassle. Nobody is making you remove/move which. If you want to
move/remove which then do it in a way that doesn't break other
people's stuff (as much as possible). In this case that really isn't
hard to do (just wait until GNU which passes NEW, and preferably file
bugs on packages that now need to depend on it).

I didn't understand why you wanted to make this change in the first
place, and I don't understand why you didn't just revert the message
when it became clear that it was a problem, and I don't understand why
you are still trying to justify your somewhat bloody-minded approach
to this (should-have-been) minor issue, even after the tech comittee
have agreed that it was not a good approach.

Please, just remove the deprecation message, until GNU which is in
unstable (like you should have done a couple of months ago, when first
asked), then work out how the transition should go such that no-one
using which will actually notice or care. Then you can throw away the
hated binary :-) and we can all be happy.

I understand that it's galling to have the TC tell you to take a
different approach, especially when you've doubled-down on your
approach, but I'm afraid the TC is correct here, so please, stop
arguing, do what's best for the project, and soon enough this will all
be over, and we'll all have what we want. And you may (or may not)
choose to reflect on the the point that we _could_ have got to exactly
the same point without this argument if you'd made different choices.

From my personal point of view this is solved short-term the moment
the deprecation message is gone in unstable, and long term as soon as
GNU which enters unstable.

I hope this is my last-ever word on this tiresome subject.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

[toc] | [prev] | [next] | [standalone]

#1078171

On Tue, Oct 26, 2021 at 12:46:43PM +0200, tito wrote:
> It is possible to create a single command package if somebody
> will maintain it ( e.g busybox-which) like it was done for busybox-syslogd.
> tempfile is missing tough.

If someone wants to do that, I suppose they can.

On Tue, Oct 26, 2021 at 01:53:29PM +0100, Wookey wrote:
> I didn't understand why you wanted to make this change in the first

I think I tried to explain this to you on another mailing list.
There are people who are dissatisfied with the status quo with
respect to which(1).  I, as a user, don't care at all about
which(1).  I, as debianutils upstream, do not want to spend any
effort maintaining a utility which is superfluous given the
existence of alternatives which are preferred by people who care
about this stuff.

Now, as a debianutils maintainer in Debian, I could choose between
various different approaches, taking into account different objectives
to accommodate different stakeholder groups.  It is important to
acknowledge that it is impossible to please all groups here.

One approach is to embrace the status quo.  which(1) is perfectly
fine as it is, and anyone who wants `which -s` or
`which --read-functions` is a fool, an idiot, or worse.  Those
people don't matter and they should shut up.  I believe that this
is roughly equivalent to the original demand at the start of this
bug report.  I'll call this the ultraconservative approach.  It is
predicated on bad values and produces a bad outcome.

Another is to cautiously embrace change at a glacial pace.  This
signals to people who want something else that they are largely
unimportant, but as a gesture of good will, they can be accommodated
eventually, maybe in 2 years, maybe in 10.  It might seem reasonable
in a subculture which is stratified and resistant to change, with
stability (even the stability of _unstable_) paramount.  I'll call
this the conservative approach.  It is predicated on bad values and
produces a bad outcome.

Another is to build a runway for people to get what they want and
remove myself from the equation.  This is what I have attempted to
do.  Now, provided anyone elects to maintain them and the FTP team
allows them in, users will be able to install and use GNU which,
*BSD which, busybox which, rewrite-it-in-rust which, or whatever
should float someone's boat.  I can think all of this is pointless,
and it doesn't matter, because I am not impeding anyone else in
their pursuit of which(1) apotheosis.

> place, and I don't understand why you didn't just revert the message
> when it became clear that it was a problem, and I don't understand why
> you are still trying to justify your somewhat bloody-minded approach
> to this (should-have-been) minor issue, even after the tech comittee
> have agreed that it was not a good approach.

You seem angry that I haven't expended effort to work around a bug
in some other software.  You also seem angry that I am not following
a process that I am explicitly calling a bad process.  Other people
have said that "this is the way Debian does things," but I have been
doing this for 25 years and I recall Debian doing things many different
ways.

I'll save my commentary on the quality of the TC's decision until after
they have made it.

> Please, just remove the deprecation message, until GNU which is in
> unstable (like you should have done a couple of months ago, when first
> asked), then work out how the transition should go such that no-one
> using which will actually notice or care. Then you can throw away the
> hated binary :-) and we can all be happy.

When will GNU which be in unstable?

[toc] | [prev] | [next] | [standalone]

#1078176

On Tue, 26 Oct 2021, Clint Adams wrote:

> effort maintaining a utility which is superfluous given the
> existence of alternatives which are preferred by people who care

“It only exists if it’s in Debian.”

SCNR. But this is relevant, here.

[ overly harsh words deleted ]

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

[toc] | [prev] | [next] | [standalone]

#1078181

On Tue, Oct 26, 2021 at 09:53:55PM +0200, Thorsten Glaser wrote:
> “It only exists if it’s in Debian.”
> 
> SCNR. But this is relevant, here.
> 
> [ overly harsh words deleted ]

That's right, so we print a deprecation warning at the beginning
of the development cycle to raise awareness of the situation and
this leads to the interested parties packaging the whiches they
want to see in Debian over the subsequent ~2-year period.

This didn't work for tempfile because everyone still using tempfile
seems to redirect stderr to /dev/null and never saw the warning.

Ironically, it seems it hasn't yet worked for the original catalyst,
but it has worked for GNU which, modulo the problem of the NEW
queue.  As a side effect, it seems to have shined a spotlight on
some broken build systems.

[toc] | [prev] | [next] | [standalone]

#1078566

On Sun, 24 Oct 2021, Clint Adams wrote:
> > In any case, a message saying that which is deprecated when in fact
> > `which` will stay around (but maintained in another packages) is not
> > helpful.
> 
> Tell me, what would be helpful?

A coordinated take over of the binary with a proper transition as
recommended by the tech-ctte.

I have sympathy with your reasoning and I can certainly relate to things
that we did 20 years ago, where we happily broke unstable after a release
but we have changed.

Yes, on some aspects we have become more conservative. I certainly wish
to change that, but not by going backwards, but by providing new avenues
to experiment and make large-scale changes without breaking unstable/testing.

> On Mon, Oct 18, 2021 at 11:50:32AM -0700, Sean Whitton wrote:
> > As Raphael has mentioned, it's unlikely that when debianutils' which(1)
> > has been replaced with one in another essential or transitively
> > essential package that the new which(1), whether it's the same code or
> > something else, will print deprecation warnings.  And then it seems odd
> > to print them for a while and then stop printing them.
> 
> I find this to be a curious statement.  This implies a contract of
> future behavior that does not exist.

Right, but that's we are doing in Debian when we discuss together and make
plans for further changes and then try to stick to the plan. You seem to
consider Debian as a more "organic entity" that is not controllable and
that you have no chance to influence.

And as often, the reality is somewhere in the middle.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

[toc] | [prev] | [next] | [standalone]

#1076144

On Wed, Oct 06, 2021 at 10:37:25AM +0100, Simon McVittie wrote:
> I was under the impression that debianutils is (intended to be)
> a Debian-specific package with no separate upstream existence. Does
> it have releases other than "whatever is in unstable"? Is there an

Yes, one of the many changes that was on hold until the bullseye
release was addressing a (non-deb) downstream request to provide
signed tarballs[0].

> upstream maintainer distinct from its Maintainer and Uploaders, namely
> you and Manoj?

For now it is I.

> "debianutils should consist of utilities maintained in debianutils"
> seems slightly circular. Is there an intended scope for what's in
> debianutils, beyond "things that need to be Essential because they
> always used to be Essential"?

I think that you may have misparsed my sentence.

> I see that CONTRIBUTING documents some of the utilities in debianutils
> as being unsupported/pending deprecation, such that if new features are
> desired, contributors are asked to instead fork the utility and coordinate
> removal from debianutils (and presumably takeover by a new package, given
> their Essential status). Can we infer the utilities you want to continue to
> maintain are everything not on that list?

I would say more that the set of utilities I think should remain in
debianutils for the time being for one reason or another is everything
not on that list.

> debianutils currently has:
> 
> - add-shell, remove-shell, update-shells: Debian-specific(?)
>   maintainer-script infrastructure for maintaining /etc/shells,
>   analogous to how init-system-helpers maintains system services.
>   Clearly at least transitively Essential, because if they were a
>   separate package, the Essential dash and bash would depend on them.

It is my hope that update-shells will obsolete add-shell and remove-shell
as well.

> - ischroot, run-parts, savelog, which (and historically tempfile):
>   these seem more like general-purpose utilities than anything else,
>   and Essential from their wide use without an explicit dependency?
>   Of these, CONTRIBUTING describes ischroot, savelog and which as being
>   unsupported (deprecated or pending deprecation) but presumably
>   run-parts is not in that category?

run-parts is special in that it is roughly feature-complete and, as
far as I am aware, there are no extant alternatives other than Red
Hat's "fork" of debianutils run-parts as a shell script.  I could be
convinced that it shouldn't be Essential though.

ischroot is pretty flawed and I continually regret acquiescing to its
incorporation.  savelog is garbage, but is, as you point out, used by
dpkg.  which was only important for maintainer scripts when POSIX only
specified alternatives like `type` and `command -v` in optional
extensions.  Now which is only important to people using bash, it seems.

>   CONTRIBUTING calls out logrotate as being better than savelog, but
>   savelog gets used by Essential packages like dpkg, and I don't think
>   logrotate is necessarily suitable to be transitively Essential.

I don't have an opinion on that, but if dpkg wants to subsume savelog,
that would be fine by me.

> Yes, and in general I think that direction is fine, as long as the
> transition away from these utilities being in debianutils is done carefully.
> 
> mktemp and readlink were taken over by Essential coreutils, with
> a transitional Pre-Depends; sensible-* were moved to non-Essential
> sensible-utils, with a transitional Depends (making sensible-utils
> transitively Essential for one release) to ensure existing systems didn't
> lose them, and presumably some reasonable plan to ensure that dropping
> them from the Essential set wouldn't break existing packages.

I can't comment on the reasonableness of the plan, as I had nothing to
do with it.

> `command -v` is not always a valid substitute for which(1). For example,
> when Flatpak's test suite builds a tiny container that includes /bin/sh
> and /usr/bin/echo, it can't use `command -v echo` because that would
> find shell builtins as higher-precedence than their ordinary executable
> equivalents. In Flatpak's case, the test happens to be a bash script
> and so can use `command -P echo` or `type -P echo`, but those are
> bash-specific and not always available in a POSIX shell.

Originally, I avoided specifying a particular alternative in the
deprecation warning because the appropriate substitute does indeed
depend on what the user is trying to do.

> None of this implies that what we might call "debianutils upstream" needs
> to be responsible for which(1) and tempfile(1) *forever*; but removing
> functionality from Essential is disruptive, so I think the maintainers
> of debianutils *in Debian* (in practice the same people?)  have a
> responsibility to ensure that debianutils.deb either continues to provide
> the Essential functionality of previous versions, or pulls in a version
> of some transitively-Essential package that takes over the Essential
> functionality so that it can become someone else's responsibility.

I think that this (short-term transitively Essential) is fine for
which(1), especially if GNU which is the only which(1) to make it
through NEW within the next year and a half.

However, I don't think that this is reasonable for tempfile(1) unless
someone is actually willing to package and maintain a tempfile(1).

> To the best of my knowledge, we don't currently have a native package that
> has the semantics of "contains things that are Essential for historical
> reasons", unless debianutils is it (which you say it isn't) or unless
> sysvinit-utils is it (but I don't think it really should be, because that
> entangles responsibility for a non-default init system with responsibility
> for Essential utilities, and it isn't clear to me that we should be
> requiring people who want to work on one of those aspects of src:sysvinit
> to take responsibility for the other).

I certainly wouldn't want anyone to be required to work on either which(1)
or tempfile(1).

On Mon, Oct 11, 2021 at 10:43:13AM +0200, Sebastian Ramacher wrote:
> I don't consider #992399 to be fixed. I specifically asked for a
> coordinated transition for the tempfile removal in that bug. So far I
> see no indication that this transition is coordinated in any way. As far

I don't know whether to be offended by anyone not seeing things.  The
stable version of tempfile(1) prints a deprecation warning.  I filed bugs.
I sent patches.  All breaking changes were uploaded to unstable at the
beginning of the development cycle so to maximize the available time for
testing.  Some people did NMUs.

> I think it would have been easy enough to follow a more systematic
> approach by processing the whole archive with piuparts to detect all the
> remaining cases.

I am not sure that piuparts could detect all cases.

> Additionally, Debian Policy 10.4 and the lintian tag
> possibly-insecure-handling-of-tmp-files-in-maintainer-script still
> recommend "tempfile or mktemp".

These seem like minor bugs in debian-policy and lintian.

> Beyond tempfile(1) in maintainer scripts, random uses of tempfile
> are still being reported. See #995583 for the latest example. But also
> for this case, I see no coordination.

> Helmut has shown how to remove interfaces from the essential set with
> e2fsprogs. But I think e2fsprogs was in a much better place when this
> was done: the interesting interfaces were moved to util-linux and for
> the remaining users of e2fsprogs it was easy enough to add dependencies.
> tempfile(1) however is used in maintainer scripts with the potential for
> upgrade failures. At least for that case I would expect that all the
> users are fixed in release $x and then tempfile could be removed in $x
> + 1.
> 
> For all the other uses of tempfile, I'm currently lacking an overview.

While I don't deny that the methodology for which Helmut advocates works,
I do deny that it is the right way to manage changes of this nature.

On Wed, Oct 13, 2021 at 01:05:50PM -0700, Sean Whitton wrote:
>    The debianutils package must continue to provide the tempfile(1)
>    program until a compatible utility is available in a package that is
>    at least transitively essential in Debian 12.

Could you define "a compatible utility"?


[0] https://clint.pages.debian.net/debianutils-tarballs/

[toc] | [prev] | [next] | [standalone]

#1076189

On Sat, 16 Oct 2021, Clint Adams wrote:

> It is my hope that update-shells will obsolete add-shell and remove-shell

Huh, what’s update-shells?

Hm, apparently something new in sid. Ouch. If you really wish for
that, it’ll involve painful versioned Pre-Depends and a largish
diff for backports :/ and, I think, at least one release in which
both are present so removing a shell in a partial upgrade won’t
fail, aborting dpkg…

> run-parts is special in that it is roughly feature-complete and, as
> far as I am aware, there are no extant alternatives other than Red
> Hat's "fork" of debianutils run-parts as a shell script.  I could be
> convinced that it shouldn't be Essential though.

run-parts is used a lot, though, as it’s rather useful.

> ischroot is pretty flawed and I continually regret acquiescing to its

Huh? -v please. I use that for some decisions on $orkplace systems.

> dpkg.  which was only important for maintainer scripts when POSIX only
> specified alternatives like `type` and `command -v` in optional
> extensions.  Now which is only important to people using bash, it seems.

No. You’re conflating “which <cmd>”, which indeed is mostly redundant
with “command -v”, with “which -a <cmd>”, which is NOT otherwise
available, and a very useful thing to have, and one which (heh, pun
not intended) I pretty much expect to exist on a system.

> I think that this (short-term transitively Essential) is fine for
> which(1), especially if GNU which is the only which(1) to make it
> through NEW within the next year and a half.

Hmmh. I personally don’t care too much which which is there, as long
as it’ll support the two(!) common uses, though ofc I’d prefer BSD ☻
but having just one is perhaps less error-prone.

> I don't know whether to be offended by anyone not seeing things.  The
> stable version of tempfile(1) prints a deprecation warning.  I filed bugs.
> I sent patches.  All breaking changes were uploaded to unstable at the
> beginning of the development cycle so to maximize the available time for
> testing.  Some people did NMUs.

I know that feeling… some package maintainers don’t seem to care about
warnings. But as something in an Essential package I fear it’s up to
you to ping them, time and time again, until they don’t depend on it
any more, instead of proactively removing it.

(I even have to support dashisms in mksh-as-/bin/sh (the lksh binary,
actually) because some bugs are so widespread…)

> These seem like minor bugs in debian-policy and lintian.

ACK.

> > upgrade failures. At least for that case I would expect that all the
> > users are fixed in release $x and then tempfile could be removed in $x
> > + 1.

Indeed.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

[toc] | [prev] | [next] | [standalone]

#1076285

>>>>> "CA" == Clint Adams <clint@debian.org> writes:

CA> However, I don't think that this is reasonable for tempfile(1) unless
CA> someone is actually willing to package and maintain a tempfile(1).

just saw this..

i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
postint script and its removal started blocking my apt upgrades.  i had
to copy tempfile over from a virt stuck on an older deb to get around it.

(cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)

it would be useful to ensure no packages rely on something before
removing it...

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web