6 ms·

Debian 12 “Bookworm” Enters Its Soft Freeze

78 points by alexis2b 4y ago

LeSaucy 4y ago
Looking forward to updating my packer/terraforms!
raziel2p 4y ago
One interesting change: > The which program has been deprecated, and writes a warning to standard error (but still works, so long as stderr is not being captured along with stdout). Shell script writers are advised to use command -v instead. Interactive bash shell users are advised to use type, or type -a. In zsh which is already a shell builtin, so interactive zsh users are not affected.
- dec0dedab0de 4y ago
  This is ridiculous, isn't it just a shell script? Why would they get rid of it? I don't get it.
  - rascul 4y ago
    There was discussion about it. https://news.ycombinator.com/item?id=29026623 https://news.ycombinator.com/item?id=29026623
    - asveikau 4y ago
      Quoted by the lwn article: > "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job". This is one of the most ridiculous takes I've heard and severely out of touch with shell scripts out in the wild, to say nothing of the expectations of Unix users typing at an interactive shell. First time I used Debian was '99 or 2000. It's been a go-to Linux distro for me for a long time. This is disappointing.
      - worksonmine 4y ago
        I stopped using which some time ago because while it worked fine to bootstrap Debian based distros I found out it wasn't included in arch. Since then I always default to command -v. I don't see the problem, it already wasn't portable and as can be seen in this thread including it gives the false impression that it was.
        asveikau 4y ago
        My house has machines running FreeBSD, OpenBSD, Linux, Mac, and lastly some old '90s Unix I never power on. Those all have which. The only portability wrinkle I've personally seen is that old Solaris behaved differently when the program isn't found. It would say "no $1 in $PATH" to stdout, whereas more recent systems just don't display anything.
    - dmd 4y ago
      Oh, according to LWN, it's Clint Adams' fault. In which case it's my fault, because in 1998, when Clint and I shared an apartment in NJ, I was pushing him backwards in a shopping cart, which overturned. He hit his head. All his decisions thereafter, I submit, are due to that.
      - syockit 4y ago
        Are you sure about that? Did you take the picture of his brain to confirm?
- gwillen 4y ago
  Beware -- command -v does not have the same semantics as which, and is not a substitute for it in shell scripts. There is no direct substitute. See: https://github.com/koalaman/shellcheck/issues/1162 https://github.com/koalaman/shellcheck/issues/1162
  - metadat 4y ago
    For most purposes, the difference is pretty nuanced and unlikely to cause a problem in real life. > 'command -v' also returns 0 for shell built-ins, whereas 'which' only searches $PATH. In what cases is one using anything to check for a built-in shell command? I've written quite a lot of bash, and this has never come up. I've learned to prefer 'command -v' because it's always available, whereas on minimal or busybox installs sometimes 'which' is not included. The annoying part seems to be more that the ergonomics of a single straightforwardly-named command (e.g. 'which') are friendlier and easier to remember compared to an unintuitively-named command requiring the addition of a flag. Why can't we move in a more ergonomic direction by promoting 'which' to a BASH built-in?
- Tao3300 4y ago
  What's the long form of "-v"? Shell scripts should use long form options for clarity. As it stands, `command -v` is inscrutable.
  - scbrg 4y ago
    There is no long form. command is defined in Posix. Long forms are a GNU addition.
    - Tao3300 4y ago
      Kind of a moot point for me since I usually install fish the first chance I get anyway, which has for its command command: > -v (or -s or --search) 'command --search' is much more accurate. To me, -v means either "version" or "verbose", and it's a stretch to say either of those words is suitable for this use case. Guess I'll have to remember it as vhich if the need arises :)
      - worksonmine 4y ago
        > To me, -v means either "version" or "verbose", and it's a stretch to say either of those words is suitable for this use case. Well it is, kind of. From bash-builtins(7): > If either the -V or -v option is supplied, a description of command is printed. The -v option causes a single word indicating the command or filename used to invoke command to be displayed; the -V option produces a more verbose description.
- teddyh 4y ago
  I was taught, back in the late 20th century, to never use the “which” program in shell scripts, since that program has its own logic on what programs are available, and that might differ from the method the actual shell uses to find programs, and this could obviously lead to subtle bugs. I was taught to use “type” instead, since, IIRC, “command” did not exist at the time.
  - asveikau 4y ago
    > I was taught, back in the late 20th century, to never use the “which” program in shell scripts, since that program has its own logic on what programs are available, and that might differ from the method the actual shell uses to find programs, and this could obviously lead to subtle bugs. This reminds me of the suggestion not to use access(2) and X_OK to decide to call execve(2) -- because the kernel behavior of executing the binary may work differently and fail for some other reason, or perhaps even there's a race condition where the executable bit gets removed between your calls. This is typical advice given to people writing shells. On this basis I would say using either which or command -v in unsound; neither of them are a guarantee that execve(2) will succeed. But like many things done in shell scripts, it's a "good enough" kind of solution that will do the right thing a majority of the time.
rektide 4y ago
Yes! Gstreamer v1.22 made the cut! So much great stuff. I was worried-- actually I though the freeze had already started... softer-freeze? https://gstreamer.freedesktop.org/releases/1.22/ https://gstreamer.freedesktop.org/releases/1.22/ https://news.ycombinator.com/item?id=34505574 https://news.ycombinator.com/item?id=34505574
- zinekeller 4y ago
  Transition and toolchain freeze (https://release.debian.org/testing/freeze_policy.html#transition https://release.debian.org/testing/freeze_policy.html#transi...), where certain critical packages (https://release.debian.org/testing/essential-and-build-essential.txt https://release.debian.org/testing/essential-and-build-essen...) are frozen and updates are discouraged (not blocked) unless that the update would be too onerous to bugtest.
- blihp 4y ago
  There are 4 freezes[1]... the soft freeze (the current one) basically freezes which packages will be in the release and the hard freeze (the next one) gets everything stabilized. [1] https://release.debian.org/testing/freeze_policy.html https://release.debian.org/testing/freeze_policy.html
endorphine 4y ago
IIRC this will include the Firefox version that supports GPU acceleration on Intel chipsets (e.g. Lenovo ThinkPad Carbon X1)? If so, this is huge!
- kasabali 4y ago
  Firefox version isn't tied to the Debian releases.
  - endorphine 4y ago
    What if you use the firefox-esr Debian package?
ebb_earl_co 4y ago
“ State of bookworm ================= … Please try out upgrading your bullseye systems to bookworm now and report issue you encounter” Roger that!
hackeraccount 4y ago
Was the movie from 11-12 really fast or is that me? I'm still moving a few servers over to 11...
- pdw 4y ago
  I don't think so. Looks like Debian 12 will be released about 2 years after the previous release, which is about typical.

78 points by alexis2b 4y ago

Looking forward to updating my packer/terraforms!

One interesting change: > The which program has been deprecated, and writes a warning to standard error (but still works, so long as stderr is not being captured along with stdout). Shell script writers are advised to use command -v instead. Interactive bash shell users are advised to use type, or type -a. In zsh which is already a shell builtin, so interactive zsh users are not affected.

dec0dedab0de 4y ago
This is ridiculous, isn't it just a shell script? Why would they get rid of it? I don't get it.
- rascul 4y ago
  There was discussion about it. https://news.ycombinator.com/item?id=29026623 https://news.ycombinator.com/item?id=29026623
  - asveikau 4y ago
    Quoted by the lwn article: > "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job". This is one of the most ridiculous takes I've heard and severely out of touch with shell scripts out in the wild, to say nothing of the expectations of Unix users typing at an interactive shell. First time I used Debian was '99 or 2000. It's been a go-to Linux distro for me for a long time. This is disappointing.
    - worksonmine 4y ago
      I stopped using which some time ago because while it worked fine to bootstrap Debian based distros I found out it wasn't included in arch. Since then I always default to command -v. I don't see the problem, it already wasn't portable and as can be seen in this thread including it gives the false impression that it was.
      - asveikau 4y ago
        My house has machines running FreeBSD, OpenBSD, Linux, Mac, and lastly some old '90s Unix I never power on. Those all have which. The only portability wrinkle I've personally seen is that old Solaris behaved differently when the program isn't found. It would say "no $1 in $PATH" to stdout, whereas more recent systems just don't display anything.
  - dmd 4y ago
    Oh, according to LWN, it's Clint Adams' fault. In which case it's my fault, because in 1998, when Clint and I shared an apartment in NJ, I was pushing him backwards in a shopping cart, which overturned. He hit his head. All his decisions thereafter, I submit, are due to that.
    - syockit 4y ago
      Are you sure about that? Did you take the picture of his brain to confirm?
gwillen 4y ago
Beware -- command -v does not have the same semantics as which, and is not a substitute for it in shell scripts. There is no direct substitute. See: https://github.com/koalaman/shellcheck/issues/1162 https://github.com/koalaman/shellcheck/issues/1162
- metadat 4y ago
  For most purposes, the difference is pretty nuanced and unlikely to cause a problem in real life. > 'command -v' also returns 0 for shell built-ins, whereas 'which' only searches $PATH. In what cases is one using anything to check for a built-in shell command? I've written quite a lot of bash, and this has never come up. I've learned to prefer 'command -v' because it's always available, whereas on minimal or busybox installs sometimes 'which' is not included. The annoying part seems to be more that the ergonomics of a single straightforwardly-named command (e.g. 'which') are friendlier and easier to remember compared to an unintuitively-named command requiring the addition of a flag. Why can't we move in a more ergonomic direction by promoting 'which' to a BASH built-in?
Tao3300 4y ago
What's the long form of "-v"? Shell scripts should use long form options for clarity. As it stands, `command -v` is inscrutable.
- scbrg 4y ago
  There is no long form. command is defined in Posix. Long forms are a GNU addition.
  - Tao3300 4y ago
    Kind of a moot point for me since I usually install fish the first chance I get anyway, which has for its command command: > -v (or -s or --search) 'command --search' is much more accurate. To me, -v means either "version" or "verbose", and it's a stretch to say either of those words is suitable for this use case. Guess I'll have to remember it as vhich if the need arises :)
    - worksonmine 4y ago
      > To me, -v means either "version" or "verbose", and it's a stretch to say either of those words is suitable for this use case. Well it is, kind of. From bash-builtins(7): > If either the -V or -v option is supplied, a description of command is printed. The -v option causes a single word indicating the command or filename used to invoke command to be displayed; the -V option produces a more verbose description.
teddyh 4y ago
I was taught, back in the late 20th century, to never use the “which” program in shell scripts, since that program has its own logic on what programs are available, and that might differ from the method the actual shell uses to find programs, and this could obviously lead to subtle bugs. I was taught to use “type” instead, since, IIRC, “command” did not exist at the time.
- asveikau 4y ago
  > I was taught, back in the late 20th century, to never use the “which” program in shell scripts, since that program has its own logic on what programs are available, and that might differ from the method the actual shell uses to find programs, and this could obviously lead to subtle bugs. This reminds me of the suggestion not to use access(2) and X_OK to decide to call execve(2) -- because the kernel behavior of executing the binary may work differently and fail for some other reason, or perhaps even there's a race condition where the executable bit gets removed between your calls. This is typical advice given to people writing shells. On this basis I would say using either which or command -v in unsound; neither of them are a guarantee that execve(2) will succeed. But like many things done in shell scripts, it's a "good enough" kind of solution that will do the right thing a majority of the time.

rektide 4y ago

Yes! Gstreamer v1.22 made the cut! So much great stuff. I was worried-- actually I though the freeze had already started... softer-freeze? https://gstreamer.freedesktop.org/releases/1.22/ https://gstreamer.freedesktop.org/releases/1.22/ https://news.ycombinator.com/item?id=34505574 https://news.ycombinator.com/item?id=34505574

zinekeller 4y ago
Transition and toolchain freeze (https://release.debian.org/testing/freeze_policy.html#transition https://release.debian.org/testing/freeze_policy.html#transi...), where certain critical packages (https://release.debian.org/testing/essential-and-build-essential.txt https://release.debian.org/testing/essential-and-build-essen...) are frozen and updates are discouraged (not blocked) unless that the update would be too onerous to bugtest.
blihp 4y ago
There are 4 freezes[1]... the soft freeze (the current one) basically freezes which packages will be in the release and the hard freeze (the next one) gets everything stabilized. [1] https://release.debian.org/testing/freeze_policy.html https://release.debian.org/testing/freeze_policy.html

endorphine 4y ago

IIRC this will include the Firefox version that supports GPU acceleration on Intel chipsets (e.g. Lenovo ThinkPad Carbon X1)? If so, this is huge!

kasabali 4y ago
Firefox version isn't tied to the Debian releases.
- endorphine 4y ago
  What if you use the firefox-esr Debian package?

ebb_earl_co 4y ago

“ State of bookworm ================= … Please try out upgrading your bullseye systems to bookworm now and report issue you encounter” Roger that!

hackeraccount 4y ago

Was the movie from 11-12 really fast or is that me? I'm still moving a few servers over to 11...

pdw 4y ago
I don't think so. Looks like Debian 12 will be released about 2 years after the previous release, which is about typical.