Program names and "pollution"

Posted Apr 3, 2019 8:18 UTC (Wed) by kandreas (guest, #131050)
In reply to: Program names and "pollution" by mrshiny
Parent article: Program names and "pollution"

The PostgreSQL project is fine with doing the work. The concern is that we will break tons of end users' scripts and pissing them off. I am one of those arguing in favor of fixing this but I know fixing it will break a ton of third party tools and in house scripts at various companies when we in 3-5 years time pull the plug and remove the legacy aliases. Even with a long deprecation cycle with warnings some people will not update their scripts.

Program names and "pollution"

Posted Apr 3, 2019 10:15 UTC (Wed) by lamawithonel (subscriber, #86149) [Link] (4 responses)

Maybe you need more phases than only Deprecation and Removal. The following would be a lot more work, no doubt, but it would give users a lot more options and opportunity to fix things.

1: Move existing commands to pg_* and create symlinks.
1a: (optional) Create a central binary with sub-commands, à la `git` or `systemctl`, and move all the pg_* commands under that. Replace symlinks with shim binaries.
2: Start printing a warning if commands are called by their legacy names, but allowi users to silence the warnings with an option flag.
3: Create a build path to build only the symlinks/shims, and a non-default way to build without them. This gives packagers an easy way to package them separately, and users a way to test without them. It also gives packagers some control over how and when they remove the symlinks/shims.
4: Make deprecation warning silence flags NOOP.
5: Inspired by rfunk's comment, move the symlinks/shims out of $PATH, to something like /usr/share/postgres/bin, and declare them unsupported. Inform users that they can add the new directory to their $PATH if they really need them for some reason, but that you won't accept bug reports against them. Maintain this for at least another major release, possibly several more.
6: Rejoice when our AI overloads remove all the symlinks/shims.

Program names and "pollution"

Posted Apr 3, 2019 10:24 UTC (Wed) by lamawithonel (subscriber, #86149) [Link]

err... 6 should actually be "invert the build option so the symlinks/shims are not built by default," 7 would be "Rejoice when our AI overlords remove all the code to build and test symlinks/shims."

Program names and "pollution"

Posted Apr 3, 2019 15:19 UTC (Wed) by kh (guest, #19413) [Link] (1 responses)

Why not create a separate package postgresql-legacy-cmds to put all the deprecated commands in. That way if some end user has a bunch of scripts they don't want to update, and they ignore all the deprecation warnings for a few years, when the commands are actually deprecated, (and this new package is no longer a dependency) all they will need to do with newer systems to fix their scripts is a quick apt-get postgresql-legacy-cmds or equivalent and they can continue to use all their old scripts, but others will not be bothered. Maybe this is already implied or suggested and I missed it.

Program names and "pollution"

Posted Apr 4, 2019 13:25 UTC (Thu) by lamawithonel (subscriber, #86149) [Link]

That's the point of #3. The first-line build system is something the developers control, and doing it there makes sure everyone gets it, be that packagers in the project, distro packagers, or users who compile it themselves. Also, in my experience, a lot of people won't even consider things like removing part of the build, so giving them a way to do it, even if they don't end up using the way provided, helps jolt imagination.

Program names and "pollution"

Posted Apr 3, 2019 17:19 UTC (Wed) by rotty (guest, #14630) [Link]

Regarding step 3 (creating a separate build path to build only shims/symlinks to aid packaging), I'd like to add that this seems likely unnecessary for distributions which have a binary/source package separation, such as Debian. Whether to include specific files, and in what package binary package to include them in, is already up to the maintainer. In the case of Debian, the `debian/*.install` files specify exactly that.

This build system feature, though, would probably helpful on source-based systems, though I'm not familiar with those.

Program names and "pollution"

Posted Apr 7, 2019 0:13 UTC (Sun) by rossmohax (guest, #71829) [Link] (3 responses)

deprecate gracefully by introducing startup delay of 10 seconds every major release

Program names and "pollution"

Posted Apr 9, 2019 1:40 UTC (Tue) by k8to (guest, #15413) [Link] (2 responses)

This is an entertaining idea. My practical perspective is as a user I would not be entertained to debug this.

Program names and "pollution"

Posted Apr 9, 2019 15:16 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Hm, you could deprecate gracefully by producing a non-interruptible animation of a steam locomotive every time someone types the old names? :P :P

Program names and "pollution"

Posted Apr 9, 2019 23:35 UTC (Tue) by karkhaz (subscriber, #99844) [Link]

You joke, but I'm pretty sure that Android did something similar to the delay thing...but I don't remember the details, maybe somebody else can furnish them. My recollection is that they wanted to force application developers to link against a new incompatible version of some library (maybe libc/bionic?). So they added a startup delay (I guess to _start() or something) and increased the delay every few weeks until the users noticed.