Microsoft’s failed attempt on Debian packaging

Just recently Microsoft Open R 3.5 was announced, as an open source implementation of R with some improvements. Binaries are available for Windows, Mac, and Linux. I dared to download and play around with the files, only to get shocked how incompetent Microsoft is in packaging.

From the microsoft-r-open-mro-3.5.0 postinstall script:

#!/bin/bash

#TODO: Avoid hard code VERSION number in all scripts
VERSION=`echo $DPKG_MAINTSCRIPT_PACKAGE | sed 's/[[:alpha:]|(|[:space:]]//g' | sed 's/\-*//' | awk  -F. '{print $1 "." $2 "." $3}'`
INSTALL_PREFIX="/opt/microsoft/ropen/${VERSION}"

echo $VERSION

ln -s "${INSTALL_PREFIX}/lib64/R/bin/R" /usr/bin/R
ln -s "${INSTALL_PREFIX}/lib64/R/bin/Rscript" /usr/bin/Rscript

rm /bin/sh
ln -s /bin/bash /bin/sh

First of all, the ln -s will not work in case the standard R package is installed, but much worse, forcibly relinking /bin/sh to bash is something I didn’t expect to see.

Then, looking at the prerm script, it is getting even more funny:

#!/bin/bash

VERSION=`echo $DPKG_MAINTSCRIPT_PACKAGE | sed 's/[[:alpha:]|(|[:space:]]//g' | sed 's/\-*//' | awk  -F. '{print $1 "." $2 "." $3}'`
INSTALL_PREFIX="/opt/microsoft/ropen/${VERSION}/"

rm /usr/bin/R
rm /usr/bin/Rscript
rm -rf "${INSTALL_PREFIX}/lib64/R/backup"

Stop, wait, you are removing /usr/bin/R without even checking that it points to the R you have installed???

I guess Microsoft should read a bit up, in particular about dpkg-divert and proper packaging. What came in here was such an exhibition of incompetence that I can only assume they are doing it on purpose.

PostScriptum: A short look into the man page of dpkg-divert will give a nice example how it should be done.

PPS: I first reported these problems in the R Open Forums and later got an answer that they look into it.

88 Responses

  1. Martin says:

    Everyone has the right to disgrace oneself on foreign ground. (Jeder hat das Recht, sich auf fremden Terrain zu blamieren.)

    Microsoft has no history in package management etc. at all. It would have been a surprise, if their packages would not break ones system completely. I do not blame them. They have their strengths in other areas, I assume.

    • It takes about at most 3 hours to read the packaging manual and a few man pages, even Microsoft engineers should be able to afford this, I think.

      • dogmatic69 says:

        You’ve obviously never made a mistake. Microsoft did not do this, some person made this and who knows what they had going on at the time. Maybe they could not be bothered to read the docs, maybe they were not provided enough time due to some other commitments.

        By the way, did you make a PR or open a ticket at all or was it straight to the m$ bashing?

        • Yes, I first posted a message on the MS R forum with these information.

        • Jim says:

          In my opinion, this seems like a failure of management to provide some oversight and assistance to the junior staff that rolled up this package. It doesn’t take a packaging guru or even someone who has just perused the documentation to know that replacing the default shell is a terrible idea!

        • Bakunin says:

          This goes beyond a mistake. We have to remember that we’re not talking about some 15-year old that wrote some wonky script here. We’re talking about a multi-billion dollar company that is known for software development (irregardless of the quality of said software). “Maybe they could not be bothered to read the docs” well then they shouldn’t have released it at all.

    • Thorben says:

      At least they didn’t rm -rf /usr.

    • Sananab says:

      I would buy that argument if they hadn’t just run a big Wumao Dang campaign on Reddit and Hacker News and other sites explaining that in the last four years they have become fun-loving, Linux-mastering, Open Source aficionados.

  2. glandium says:

    If anything, all this is proving is that dealing with these things in Debian packages is not straightforward. I don’t think this is thoroughly covered in the Debian reference.

    • It is not that complicated and well documented. And above all, just simply asking a few questions will give you good answers within a very short time. So there is no excuse for this kind of packaging.

      • Eli Uriegas says:

        I think for this case in particular it’s pretty damning for a post install script to remove /bin/sh

        That’s something that should never be done by a post install script EVER. In most cases as well you don’t ever touch anything in /bin/ anyways.

      • Jonathan says:

        Do we have a way for a package to say “this won’t work unless /bin/sh is bash”? Or do we instead insist that all scripts/programs that are packaged and declare themselves to work with /bin/sh must be POSIX compliant (in other words, change the programs)? I think we lean towards the latter.

        • At least in Debian if it only asks for sh, it needs to be POSIX compliant. AFAIR this was a release goal two or three releases ago.

        • Zoredache says:

          You could just update your script to use #!/bin/bash? Instead of screwing around with the system /bin/sh.

        • Anonymous says:

          No, you have to put #!/bin/bash at the top of scripts that expect bash.

  3. Anonymous says:

    The blame is on Debian for accepting such scripts in the first place. Relinking `sh` is particularly unforgivable.

    • This is not a package of Debian proper, and would never be able to enter Debian. There is nothing to blame Debian here, only that bad packaging of Microsoft.

  4. Penelope says:

    Only to put this in perspective: This ain’t someone with no coding experience doing a little hobby thing he hopes someone will find useful, this is Microsoft with employees with ->FAT<- salaries.

  5. Sven says:

    Nice one, Microsoft.

    Some years back I stumbled upon a package by a big vendor which replaced the system libc6 with their own version by bluntly untar’ing it from an archive they shipped in the postinst. You can not begin to imagine the havoc this of course caused.

    • Wow!!! That is really impressive. Compared to replacing libc, Microsoft’s errors are child’s play …

      • Sven says:

        It was shortly after the release of Sarge. I believe they wanted to support it without rebuilding their tools relying on glibc2.2 when Sarge was already on glibc2.3. So they just overwrote the system glibc with their own older version to get their code to work.

        How they thought this would a) work and b) go unnoticed I never figured out.

        • Nick Alcock says:

          Of course it would work! It worked when they tested it (on a system with exactly the same glibc they were untarring).

          But, again, there is a missing feature here: glibc should have a way to say “build a package that will work with older glibc $X”: it has all the compat symbols necessary to do so. But this feature has never materialized, leaving people who want to make cross-distro-compatible binaries with a choice of unpleasant alternatives. (Plus the alternative you mention here, which is less “unpleasant” and more “horrifically broken kill kill kill”.)

  6. “Never attribute to malice that which is adequately explained by stupidity.” Microsoft gave
    the task to somebody who had no experience whatsoever with packaging. Anybody who
    tries it the first time ends up with something like this.

    • Not if you care about reading a bit of documentation, though!

      • A random passer-by says:

        Are you sure? I did a lot of mistakes that could be avoided by RTFM, but I either didn’t know that I should read this specific document among the bazillion of others, or I was simply overwhelmed by what the bazillion of documents was telling me. Especially when half of it is for an old version, but nobody cared enough to update it yet, or some other things are documented so a master of the system will understand it, but not a newbie, and attempts to google more details lead to bad pieces of advice on various blogs or StackOverflow.

        Or it might be one of the “I need to get it working on these devel/testing machines with this hack but fix it before public release” stuff that was forgotten a few weeks later because the script just worked. Anyone who says they didn’t ever do such a thing either began working in the field today, or they do it daily. 😀

    • Jürgen Erhard says:

      No, not everyone ends up with this. If you know Debian even a *bit* (and if you don’t, why do you want to create packages for it?), you’d know about Policy. Heck, “Standards-Version” is a… okay, it’s only a recommended field, but how do you learn doing packages? Most start by updating/copying one. If you don’t even care to *TRY* to understand what you’re copying, you should lose your dev license (luckily and sadly, no such thing). Yes, SO is evil 😉

  7. Anonymous says:

    scrolling the code does not work in firefox

    • Indeed, very strange, I need to check. Thanks for the hint.

      • Anonymous says:

        It does not work in chrome 67.0.3396 as well. I guess you also did not read the documentation or test it properly. Do this first before bashing others.

    • Wynn Slater says:

      Nor in Chrome.
      This is rudimentary stuff. Clearly, the scrolling is broken on purpose. 😁

  8. William Cody Laeder says:

    You do realize the dash (debian-ash shell) debian’s bash emulator. detects if its symlinked as `sh` and will emulate it as such?

    A lot of ubuntu and debian flavors use this behavior by default.

  9. Arsen says:

    I’d like to mention that the ln -s would have no effect if the link already exists (see the -f flag for ln), but regardless this is a very very surprising thing for something so simple that I automated the whole release process for Debian in like seven or so lines of simple bash scripting. Took me like an hour to figure out how the entire thing works by reading the Debian wiki. I’m perplexed by them right now.

  10. Andrew Wei says:

    Pray for github

  11. Sebastian Martin Dicke says:

    If /usr/bin/sh is not a symbolic link but the name of the (most often) used standard user shell itself, there could be problems if someone try to login or open new shell sessions. There are no reason why not anybody could move e.g. /usr/bin/bash to /usr/bin/sh to speed up access by avoiding symbolic link solution.

  12. M. Rahman says:

    It’s not packaging error if you do it deliberately. Even when I was new to Linux I never dared to `rm /bin/sh` . Break someones system ,then advertise fixing. Classic M$

  13. Svick says:

    Did you [report the issue to them](https://github.com/Microsoft/microsoft-r-open/issues)?

  14. Roman says:

    Geez Microsoft. Stick to snaps and leave the rest of my machine the hell alone

  15. Chris Chiesa says:

    I spent the years 1998-2009, inclusive, programming on one or another flavor of Linux for a living, then spent 2011-2013 programming on Windows for a living for the first time ever. (In 2010 I programmed on QNX, which is kind of *nix-like, but I don’t know whether that counts.)

    Only in the Windows environment did my work ever involve creating a package, and for that I used a canned, point-and-click tool and just barely had any idea what I was doing.

    Throughout all those years, I used one or another (sometimes more than one concurrently) version of Windows at home and did little-to-no Linux stuff in my free time.

    If, after all these years of mostly-Microsoft at home, Linux-but-no-installation-stuff at work, I had suddenly been tasked to make an installation package for Debian or *any other* flavor of Linux, I would have been *totally lost*, even if it had been 99.9% automated — let alone if I’d had to code any of it by hand. So I can *very well imagine* engineers who’ve spent their entire careers at Microsoft doing things in a very, very, *VERY* un-Linux-y way and thus developing decades-long very, very, *VERY* un-Linux-y habits of thought, possibly getting it a bit wrong compared to you guys who can glance at shell scripts and immediately zero in on things the rest of us would have to carefully look up in the manpages even to *understand*, let alone catch as being wrong.

    I’m not saying there’s any excuse for *releasing a commercial product* in that condition, if that’s what they did — only that it’s not at all outside the realm of possibility, even probability, that something like this would be pretty much inevitable — and will likely continue to be, for a while, until Microsoft either retrains an army of people -or- wises up and hires an army of people who -already know how- to think Linux-ishly.

  16. Igor says:

    This is a rudimentary stuff – an application has no business messing with system packages. It has nothing to do with Debian, or any other distro – it’s sys admin 101. This will not be covered in any packaging documentation as this has nothing to do with a package format, it’s that basic.
    Microsoft has massive resources so if it was a junior developer, someone who’s new to Linux etc of all the companies around Microsoft can hire/contact someone who knows – even just to create a package. This is not a “hobbyist” doing something at home in spare time.
    Absolutely no excuse for releasing something like this. I’ll be inspecting closely any packages coming from Microsoft from now on.

  17. Gabo Kete says:

    This seems to me like an amateur error.. no *serious and skilful* Unix/Linux admin would do an error like that

  18. Anonymous says:

    What is the purpose for Microsoft to replace the shell?

    • LtWorf says:

      dash supports less things than bash… most likely the person didn’t know you can just use #!/bin/bash in the script header, if you want bash, rather than doing that.

      Probably read some very misguided advice off a blog

  19. UlchabhanRua says:

    IMO this is just following a long tradition of poorly created Debian packages. Yes, Microsoft should know better, especially considering how many Linux people they employ these days, but there are a many packages that do a lot of harebrained things. Any sysadmin worth their salt has run into packages that will simply die if a group they’re creating already exists, or packages that leave behind cruft in spite of doing a -purge. One could easily have an entire blog dedicated to Debian packaging wtfs and have enough material for years. This is the tip of the iceberg.

  20. NourEddineX says:

    I did read a dlink driver installation script that contained:
    rm -rf /usr/bin/ModemManager
    this was the worst thing I’ve ever read

  1. 2018/06/12

    […] Microsoft’s failed attempt on Debian packaging 3 by LopRabbit | 0 comments on Hacker News. […]

  2. 2018/06/12

    […] Microsoft’s failed attempt on Debian packaging 3 by LopRabbit | 0 comments on Hacker News. […]

  3. 2018/06/12

    […] Microsoft’s failed attempt on Debian packaging 3 by LopRabbit | 0 comments on Hacker News. […]

  4. 2018/06/12

    […] Microsoft’s failed attempt on Debian packaging 3 by LopRabbit | 0 comments on Hacker News. […]

  5. 2018/06/12

    […] Microsoft’s failed attempt on Debian packaging 3 by LopRabbit | 0 comments on Hacker News. […]

  6. 2018/06/12

    […] Microsoft’s failed attempt on Debian packaging 3 by LopRabbit | 0 comments on Hacker News. […]

  7. 2018/06/13

    […] Recommended Read: Microsoft’s failed attempt on Debian packaging from Tumblr https://chrisshort.tumblr.com/post/174849289506 via IFTTT […]

  8. 2018/06/14

    […] de Microsoft R Open sur les systèmes basés sur Linux. (Merci à Norbert Preining pour qui a signalé le problème .) Le problème était que les scripts d'installation et de désinstallation modifiaient le […]

  9. 2018/06/14

    […] with the installer for Microsoft R Open on Linux-based systems. (Thanks to Norbert Preining for reporting the problem.) The issue was that the installation and de-installation scripts would modify the system shell, […]

  10. 2018/06/14

    […] According to Norbert Preining, a mathematician living in Japan, version 3.5 of Microsoft’s Debian package for Open R contained an unsafe install and uninstall scripts that modified system-wide settings, a big no-no in the realm of Linux packages. […]

  11. 2018/06/14

    […] According to Norbert Preining, a mathematician living in Japan, version 3.5 of Microsoft’s Debian package for Open R contained an unsafe install and uninstall scripts that modified system-wide settings, a big no-no in the […]

  12. 2018/06/14

    […] According to Norbert Preining, a mathematician living in Japan, version 3.5 of Microsoft’s Debian package for Open R contained an unsafe install and uninstall scripts that modified system-wide settings, a big no-no in the […]

  13. 2018/06/14

    […] According to Norbert Preining, a mathematician living in Japan, version 3.5 of Microsoft’s Debian package for Open R contained an unsafe install and uninstall scripts that modified system-wide settings, a big no-no in the realm of Linux packages. […]

  14. 2018/06/14

    […] with the installer for Microsoft R Open on Linux-based systems. (Thanks to Norbert Preining for reporting the problem.) The issue was that the installation and de-installation scripts would modify the system shell, […]

  15. 2018/06/14

    […] issue was brought to light earlier this week by developer Norbert Preining, who found that the Debian GNU/Linux version of Open R – Microsoft’s open-source implementation of the […]

  16. 2018/06/15

    […] Microsoft los fallos hallados en los mecanismos de instalación y desinstalación de R Open 3.5, ha comentado lo siguiente: “Supongo que Microsoft tendría que leer un poco, en particular sobre dpkg-divert y […]

  17. 2018/06/15

    […] fallos hallados en los mecanismos de instalación y desinstalación de R Open 3.5, ha comentado lo siguiente: “Supongo que Microsoft tendría que leer un poco, en particular sobre […]

  18. 2018/06/15

    […] Microsoft los fallos hallados en los mecanismos de instalación y desinstalación de R Open 3.5, ha comentado lo siguiente: “Supongo que Microsoft tendría que leer un poco, en particular sobre dpkg-divert y […]

  19. 2018/06/18

    […] Microsoft) для Debian и Ubuntu, в установочном сценарии которого обнаружена серия недопустимых оплошностей. В частности, скрипт […]

  20. 2018/06/19

    […] математик Норберт Прейнинг (Norbert Preining) обнаружил, что пакет Open R версии 3.5 при установке на Debian без […]

  21. 2018/06/23

    […] Microsoft) для Debian и Ubuntu, в установочном сценарии которого обнаружена серия недопустимых оплошностей.В частности, скрипт […]

  22. 2018/07/26
  23. 2018/08/04

    […] Microsoft’s failed attempt on Debian packaging […]

  24. 2018/08/10
  25. 2020/12/08

    […] Microsoft) для Debian и Ubuntu, в установочном сценарии которого обнаружена серия недопустимых оплошностей.В частности, скрипт […]

  26. 2021/10/05

    […] less dare install a DEB or RPM from the company that, when they packaged R, deleted /bin/sh and turned it into a symlink to bash on Debian (which not only isn’t what the operating system is expecting, as dash is the non-interactive […]

  27. 2021/10/05

    […] not for you.”Much less dare install a DEB or RPM from the company that, when they packaged R, deleted /bin/sh and turned it into a symlink to bash on Debian (which not only isn’t what the operating system is expecting, as dash is the non-interactive […]

  28. 2021/10/06

    […] not for you.”Much less dare install a DEB or RPM from the company that, when they packaged R, deleted /bin/sh and turned it into a symlink to bash on Debian (which not only isn’t what the operating system is expecting, as dash is the non-interactive […]

  29. 2022/11/20

    […] According to Norbert Preining, a mathematician living in Japan, version 3.5 of Microsoft’s Debian package for Open R contained an unsafe install and uninstall scripts that modified system-wide settings, a big no-no in the realm of Linux packages. […]

Leave a Reply to Sebastian Martin Dicke Cancel reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>