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.
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.
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.
Thanks for that, Norbert. Your input was instrumental for the team to release an updated version of the package addressing some of the concerns. (Full link to the forum mentioned is https://aka.ms/Oxbegy)
Yes indeed, they have already released a new version, see my follow up blog.
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!
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.
At least they didn’t rm -rf /usr.
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.
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.
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.
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.
You could just update your script to use #!/bin/bash? Instead of screwing around with the system /bin/sh.
No, you have to put #!/bin/bash at the top of scripts that expect bash.
https://en.wikipedia.org/wiki/Hanlon%27s_razor 🙂
Indeed!
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.
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.
Indeed, not even the time of reading documentation for a few hours …
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 …
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.
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”.)
“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!
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. 😀
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 😉
scrolling the code does not work in firefox
Indeed, very strange, I need to check. Thanks for the hint.
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.
Nor in Chrome.
This is rudimentary stuff. Clearly, the scrolling is broken on purpose. 😁
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.
Yes, I know about dash, but what does this have to do with the post?
>detects if its symlinked as `sh` and will emulate it as such
Dash is not a bash emulator
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.
Yes, the ln -s will not work, as I wrote myself.
Oh – somehow I went until now with the rm unnoticed. My bad.
Pray for github
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.
You have no idea of what you’re talking about.
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$
Did you [report the issue to them](https://github.com/Microsoft/microsoft-r-open/issues)?
Not there, but in the forums and 3h ago I got an answer that they will look into it.
Geez Microsoft. Stick to snaps and leave the rest of my machine the hell alone
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.
There is a special mailing list on Debian meant for newcomers in packaging: debian-mentors@lists.debian.org
I am wondering why the MS engineers didn’t ask there… They could even upload the package and ask for a review.
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.
FFS submit a bug report or PR instead
Done so, as written at the bottom of the blog
This seems to me like an amateur error.. no *serious and skilful* Unix/Linux admin would do an error like that
What is the purpose for Microsoft to replace the shell?
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
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.
I did read a dlink driver installation script that contained:
rm -rf /usr/bin/ModemManager
this was the worst thing I’ve ever read