2 ms·

If they replaced 'wget', and you need HTTP2 support, you might be using the old 'wget' without HTTP2 support, or the new one with it. You would have to wrap all

If they replaced 'wget', and you need HTTP2 support, you might be using the old 'wget' without HTTP2 support, or the new one with it. You would have to wrap all your commands with a version check, and ask people to install the newer, different software package, to get HTTP2 support. Or, call 'wget2' to get HTTP2 support. You can then either install both 'wget' and 'wget2', or the package maintainers could install a symlink for 'wget' backwards compatibility, so you'd only need to install the newer 'wget2' package. From the package maintainer's perspective, they're literally different software projects, and changing an established package name to be different software would break many systems.

Fnoord 7y ago
This could be solved with wget1 for Wget 1.x, and wget/wget2 binaries (linked) for Wget 2.x. Only thing that does is break scripts.
- peterwwillis 7y ago
  > Only thing that does is break scripts That's not really an acceptable change... Would you like all the scripts you run on your Linux distros to break every time you do package updates? I wouldn't touch such a distro with a 100 foot pole
  - Fnoord 7y ago
    Who said there's no grace period? Python 2/3 is dealt with the same way. On 1) a rolling distribution not called NixOS 2) which mindlessly installs wget2 3) and does not use their own power to install or name the binaries according to their own view, sure 4) nor use a grace period and badly informs the user(s) which something like Homebrew would... then yes, it is a problem. On a distribution which has stable and LTS releases such as Fedora/Ubuntu/Debian it is no problem as long as users would read the release notes. It could be a problem on Arch and Gentoo, but whenever those users run into trouble you could argue PEBCAK or go fix it yourself. Same for those running -CURRENT on *BSD.
    - deleted 7y ago
      [deleted]

Fnoord 7y ago

This could be solved with wget1 for Wget 1.x, and wget/wget2 binaries (linked) for Wget 2.x. Only thing that does is break scripts.

peterwwillis 7y ago
> Only thing that does is break scripts That's not really an acceptable change... Would you like all the scripts you run on your Linux distros to break every time you do package updates? I wouldn't touch such a distro with a 100 foot pole
- Fnoord 7y ago
  Who said there's no grace period? Python 2/3 is dealt with the same way. On 1) a rolling distribution not called NixOS 2) which mindlessly installs wget2 3) and does not use their own power to install or name the binaries according to their own view, sure 4) nor use a grace period and badly informs the user(s) which something like Homebrew would... then yes, it is a problem. On a distribution which has stable and LTS releases such as Fedora/Ubuntu/Debian it is no problem as long as users would read the release notes. It could be a problem on Arch and Gentoo, but whenever those users run into trouble you could argue PEBCAK or go fix it yourself. Same for those running -CURRENT on *BSD.
  - deleted 7y ago
    [deleted]