Hacker News new | comments | show | ask | jobs | submit login
Microsoft’s failed attempt on Debian packaging (preining.info)
123 points by LopRabbit 3 months ago | hide | past | web | favorite | 106 comments



Having written horrible Debian scripts for open source software that involved setting up postgres, a java package, some python websites with apache and seeing the mess I made even with the best intentions [0] I think the article is too harsh.

Whenever anyone contributes to open source our reaction should be based on love, not hate, even if they mess up. They will eventually fix it up as opposed to deciding not venturing into unknown territory anymore.

[0] https://github.com/GeoNode/geonode/blob/master/package/debia...

(Edited to fix typo and formatting)


Sorry but one can never be too harsh when reading "rm /bin/sh" in a shell script.


Was there ever a stage in your development where you might have done something like that? This is a rhetorical question because we were all there at some point - even if it was age 8 with a first computer.

If people are displaying good intentions, and not wildly ignoring a load of clear instructions, then engaging with them will have a much greater chance of producing an educated, productive member of the community, and the more of those the better.


Agreed in general, but also, your argument rests on likening Microsoft to an eight year old using their first computer.

Microsoft surely has the means to hire someone who is not an eight year old using their computer for the first time.


Microsoft is a very big company, with everything from interns and developers only with Windows experience through to seasoned nix developers.

This error is actually a good thing from point of view - it's an anecdatum that the whole* company is engaging with open source, not just the bits that know it well. This is something we should encourage and educate. The advantage of educating someone at Microsoft as that their institutional knowledge will persist some fraction of it, so that the next person that comes along is less likely to have issues.


Two words: code review.


Also it's not just a silly commit that was made on github but an actual software release. Any other software developer would be (and have been) mocked just as hard.


I've made many mistakes in my life but I always had enough respect for technology to not yank out parts of a system which I did not understand.


I've always had enough interest in technology to be willing to yank out parts of a system which I did not understand - to see what breaks, and through that, gain understanding.

That said, I'm pretty sure the original author knew and understood exactly what they were doing - writing a dirty hack.


Did you often yank out parts of other people's systems which you did not understand?


Only when I didn't understand the full impact of the hack I used.


> to yank out parts of a system which I did not understand - to see what breaks, and through that, gain understanding.

On your development machine or on machines of other people all around the world? You can also gain understanding from the later, too.


Was there ever a stage in your development where you might have done something like that? This is a rhetorical question because we were all there at some point - even if it was age 8 with a first computer.

The great thing about those early machines ( Apple ][+ ) is that the dynamic programming language was the OS and was the REPL and that was all in ROM, so you could tinker around to your heart's content and hit the Reset button if you got stuck. That's a context that's just fine for learning. Packaging for archives installed on other's machines aren't that kind of context.

A kid gets to play in a playroom with some toys, not in a surgical theater or a machine shop.


> Was there ever a stage in your development where you might have done something like that?

I'm still willing to write worse! As a temporary hack with a JIRA issue tracking it, to unblock work, and with the intention of fixing it quickly, but still willing nonetheless.

Meanwhile the code blocks on this website lose their scrollbar and pop atop everything if you hover over them, making it near impossible to scroll right through some kind of abuse of JavaScript. Why?!? Shall I snark about incompetence too? I can't even rationalize this one to myself as a means of unblocking development like I can with the packaging hack!


Yes, it was years before I even thought of applying for a developer position. I don't suppose that's the bar to clear for a company of Microsoft's stature, even if it's the work of a fresh intern.


> Was there ever a stage in your development where you might have done something like that?

I think I would have done a little bit of reading. I also think it's the norm.


On a related note, I saw this piece of code in a vendor's install script. Not a Debian package, but an executable install script. One of the environment variables has been censored to anonymize the vendor, but everything else is verbatim.

    # Delete & recreate directory <BLAH>/Patches/<patchLevel>/
    # This will confirm write access to BLAH_HOME
    rm -rf $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL}
    mkdir -p $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL}
This is horryfing. No checking the contents of the environment variables. No checking the return codes. WTF.

(and IIRC if you google the snippet, you can find where a coworker of mine posted it to Reddit to lampoon it)


Edit: Just nevermind. I don't want to be the target of this hate train.


Aside from the fact that it leaves a window where there is no /bin/sh on the system, because it is not using atomic replacement, that is not what the script is doing. This is a Debian package. /bin/sh has been the Debian Almquist shell for almost three quarters of a decade at this point.

* https://lists.debian.org/debian-release/2007/07/msg00027.htm...

* https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy...

* https://wiki.debian.org/DashAsBinSh

* https://wiki.ubuntu.com/DashAsBinSh

* https://wiki.ubuntu.com/DashAsBinSh/Spec


It's not a requirement for /bin/sh to point to bash, only that it be a POSIX shell. The user might have chosen "dash" instead, and the one guy out there who doesn't have "bash" installed might find his system no longer boots.


In Debian, bash is an essential package. You can assume it's always installed.


Not necessarily, imagine for example an embedded OS with only dash or busybox based on Debian.

Also, even with bash installed, bash doesn't always behave like sh does.

A common example is echo:

With /bin/sh on an OpenBSD:

>>>

kakwa@openbsd ~ sh -c 'echo "print\n"'

print

<new line>

>>>

With /bin/dash (aka /bin/sh on Debian)

>>>

kakwa@debian dash -c 'echo "print\n"'

print

<new line>

>>>

This is consistent so far.

But, now, with /bin/bash

>>>

kakwa@debian ~ » bash -c 'echo "print\n"'

print\n

>>>

That's why I tend to use printf more than echo in my shell scripts.

Also, I'm not a big fan of what RHEL/CentOS/Fedora does symlinking /bin/sh and /bin/bash. It blurs the line between bash and sh, which results a lot of scripts with a /bin/sh shebang containing bashism.


OK, fine, then don't add it to the Depends field. But don't replace randomly things with a symlink to bash just because it's installed. If the scripts fail because /bin/sh is not bash, update your fsckin' broken shee-bang line.


You can make assumptions like that if the consequences are not serious. In this case boot fails next time if your assumption is wrong.


"Essential" is not some arbitrary assumption, but a term of art specific to Debian Policy, and a flag applied to specific packages:

Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the “Unpacked” state. Packages are tagged essential for a system using the Essential control field. The format of the Essential control field is described in Essential.

https://www.debian.org/doc/debian-policy/#essential-packages

Diversions are addressed in 3.9: https://www.debian.org/doc/debian-policy/#maintainer-scripts

Debian Policy, generally, tells package maintainers, not users, what they may or may not do. Several classes of conflict are listed in the document; Microsoft's scrips violate multiple requirements.

The goal and result of this ststem, arrived at over 21 years collaborative development (Policy was first published in August 1996) is a system which provides well over 60,000 packages and behaves surprisingly robustly from the user-administrator's perspective. Which is to say, there are few surprises.

Microsoft have violated multiple Policy requirements. This is considered a release-critical bug in distro packages for very good reasons.



Uh, I find unrelated software messing with my shell potentially catastrophic.

We absolutely blacklist software pulling crap like this - it is a loud, blinking demonstration that the packager is incompetent and will do other, potentially less obvious dangerous things out of ignorance or impatience. Or is there a darker explanation? Untrustworthy, in either case.


Reminder for myself: the right level to respond is the minimum level which will trigger a correction.

https://www.youtube.com/watch?v=OkebMyDvmxs

Search also Jordan Peterson on how to tickle a baby.


They will eventually fix it up as opposed to...

The team released a new package a few hours ago after talking to not only others at MSFT working with Debian and Linux but especially norbusan (OP): https://aka.ms/Oxbegy

I personally spent just a few hours of the last day with the team but I think our packaging practices are coming out stronger from this. At the very least I think this team is approaching debconf and dpkg-divert and update-alternatives (and the portions of those concepts that can translate to RPM) in a much more thoughtful way. I'm sure that was also what OP intended.

(Disclaimer: MSFT employee, just in case.)


If I publish accidentally a package with rm -rf / in the post installation script, a number of people will angry at me and frankly, I would understand them.

That being said, aside from distribution packages, always look at the pre/post (un)install scripts for external packages.

rpm -qp --scripts <PACKAGE>.rpm

dpkg is a little less convenient but:

ls control.tar.* # <<< check that no file like that already exists

ar -vx <PACKAGE>.deb

tar -xvf control.tar.*

for i in pre* post;do printf "\n>>> %s\n" "$i";cat $i;done

rm -f conffiles control control.tar. data.tar.* debian-binary md5sums postinst postrm prerm postrm

In most cases if the script is huge, the packaging tends to be horrible and generally, the quality of the software is also not that great.

Another good indicator is the installation path:

dpkg -c <PACKAGE>.deb

rpm -qpl <PACKAGE>.rpm

If there is no effort made by the editor to follow the FHS or at least be nice and put its messy bundle inside /opt/<COMPAGNY>, it's generally a bad sign.

Proprietary software tends to be quite horrible in that regard, I'm still traumatized by the trendmicro serverprotect rpm (AV for linux).

http://downloadcenter.trendmicro.com/index.php?regs=NABU&clk... (if you want to give it a try, don't forget the service pack and the product patch...)


`dpkg -I foo.deb` tells you which control components are in a package. If it has a postinst, `dpkg -I foo.deb postinst` will show it to you.


It's not as bad, but the script used to build deb package for azure-cli is a bit weird and not really a thing of beauty:

https://github.com/Azure/azure-cli/blob/dev/build_scripts/de...


> What came in here was such an exhibition of incompetence that I can only assume they are doing it on purpose.

No. This is how you escalate conflict, not resolve it.

See also: Hanlon's Razor: https://en.wikipedia.org/wiki/Hanlon%27s_razor


The vast majority of the time, malice is just an elaborated form of stupidity, anyhow.


That's nice and also fun. Are you quoting someone or is it your original idea?


I just came up with it, though I wouldn't be surprised if someone else said it before. Really, it's just recounting my life experience.


because that's what "Hanlon's Razor" states ;)


Somehow, I'm reminded of a South Park song!


I was astonished to see that Microsoft provided this software (R) under the terms of GNU GPLv2 or GNU GPLv3 explicitly (but not any later version)[0]. May be because this is a derivative work from GNU R.

That's a good news for free software developers. Microsoft GVFS[1] was using MIT (while git itself is GNU GPLv2) + some EULA[2]. May be they chose MIT for GVFS because GNU GPL license explicitly disallows additional restrictions (ie, EULA can't be added, otherwise it will tbe a violation of GNU GPL).

Edit: I see that the package is distributed as a single binary at https://mran.microsoft.com/download Which shall include (I haven't checked the contents) Microsoft R Open under GNU GPLv2 and Intel MKL with some EULA (ie, additional restrictions). Won't that be a violation of GNU GPLv2?

[0] https://mran.microsoft.com/faq#licensing

[1] https://github.com/Microsoft/GVFS

[2] https://github.com/Microsoft/GVFS/blob/master/GvFlt_EULA.md


No, it's an aggregation which is fine. In more detail: packaging gpl and non gpl software next to each other is fine, even if your package format is a single binary.

Linking mkl into gpl software and distributing the binary would not be okay because you don't have source to mkl you can give people (mkl has binary blobs). When you link software like this, you need to be able to distribute the combined binary under gpl, and unless mkl has changed, you can't.

It would be fine to link it and use it locally of course, just not distribute it.


This might be off-topic, but time to chime-in with my experience of packaging an open source software written in python.

Once, I spent a good deal of my time making a grammar-based phonetic transliterator engine for an Indic language. I was mostly a python developer with some prior experience in C and plain Make files. After a couple of rewrites, I was mostly happy with the results. Then was the time for packaging and making it a usable software. The application needed to install some files under root so that linux's input subsystem (IBus) could recognize them. Also, it dependent on some system packages(both python based and non-python based) like dictionaries for generating suggestions.

As I approached the problem, I learned that I had to learn autotools and a bunch of very debian specific scripts which were pretty much focused on packaging applications written in C. It was like an arcane magic. I would probably had to produce & package at least 10 software to make the return of investment on that knowledge. I also tried to use python's setuptools, which felt equally dirty without the benefit of generating a proper .deb package. The impedance mismatch of the whole packaging architecture and dynamic language ecosystem was soul crushing.

In the end, I wrote a python script which dumps the project in /opt and installs/uninstalls the system files and called it a day.

The end result was that user adoption of my software was very low. One reason for that might be the unusual way of installation(download a tar file, unzip and run a installer from command line).


Did you consult the NMG or ask for assistance?

https://www.debian.org/doc/manuals/maint-guide/

Otherwise, your comment lays out the cost/benefit: Debian requires software fit specific standards. The reward is an unparallelled distribution and maintenance system.

Note too: there's plenty of python-based software in Debian.

https://www.debian.org/doc/packaging-manuals/python-policy/p...


Yes, I did try to comprehend the NMG, but didn't ask for anyones help. But AFAIR, back then (mid 2015), the python specific parts of the packaging manuals were scattered between some presentations and loose documentation here and there. Thanks for the link though. I might get back to it.

Still, I believe that a robust system like debian could be achieved by more simpler means. It's packaging system is an invention of a different era and needs more streamlining to accommodate dynamic language developers. Python was invented in 90's and it's took 20+ years for debian to setup some serious guidelines for python developers. What if I want to package a software written in another dynamic language which was invented a month ago? These questions need to be addressed.

Disclaimer: I am not claiming that I could device a solution. Just that, despite my best intentions and best of efforts, I couldn't handle the difficulty of packaging.


> Python was invented in 90's and it's took 20+ years for debian to setup some serious guidelines for python developers.

I've only ever packaged in-house (within a company I'm working for) Python apps, very simple opern-source apps and libraries and modified existing packaging for new versions of such open source code that otherwise already had available packaging [1], but my experience has been different to the point that I disagree [2].

Since I'm a sysadmin and not a developer, my strategy was not just to use the documentation, but also to look at how other packages handled certain situations, especially if I knew of an app that was relatively complicated in terms of build process. For Python, that was mostly a challenge of unravelling each developer's build/install instructions (easy_install/setup.py/pip) into something that matched an existing debianized Python package.

> Still, I believe that a robust system like debian could be achieved by more simpler means. It's packaging system is an invention of a different era and needs more streamlining to accommodate dynamic language developers.

As a sysadmin, I object to the characterization of the debian package system as being "of a different era", mostly because I don't believe there's anything about this era, nor about dynamic languages (which have been around for a very long time anyway) that has eliminated the needs that it addresses.

That robustness is achieved because of the requirement of up-front effort to conform to a standard that has remained stable across eras.

> What if I want to package a software written in another dynamic language which was invented a month ago?

Same as for every other language since the beginning of time: put in the effort (including asking for help from the community) and conform. If you need a language-specific standard (such as the OS-default for egg-equivalents), then make one up (consistent with other languages) and get your new language's community behind it, if that's possible.

Of course, the other option is just to exist exclusively within that language's ecosystem (e.g. pip, gem, cpan) and wait for other interested parties to do the OS-level packaging for you. That happens, too, but it can slow adoption if your "market" is production environments and not just other devs in the ecosystem.

[1] Although sometimes with inadequate/inaccurate "debianization" (e.g. missing expicitly listing a depency)

[2] I do agree that the documentation isn't necessarily organized in the best fashion, nor that the latest info is in one place, but it's out there. There might also not be One True Way, but it's arguable if that's a bad thing.


One reason for that might be the unusual way of installation(download a tar file, unzip and run a installer from command line).

That's not too far off from how I install new versions of golang. Just leave out the last step and add a 0th step where you delete the old version first.


That obviously isn't how it should have been done, but the real problem here is that the packaging system makes it too easy to do this in the first place.

If you use pre and post and preun and postun (rpm terminology) it almost always is a sign of a deficiency elsewhere, especially when run against files outside of your package's bailiwick.


There's nothing wrong with using such scriptlets, especially in the case of dpkg diversions like the author of this article mentions.

Of course, touching files outside of your package is still a no-no.


Maintainer scripts are still very valuable, we use those in other packages (such as Code) for update-alternatives and they can be really useful in APT-based systems for user prompts via debconf. But, at any rate, we weren't thoughtful (at all) on what we did with those scripts. The team addressed that earlier today, using maintainer scripts: https://aka.ms/Oxbegy


Looks like the problem existed (on their RPM package) since 2016[1], notably, the reason given by their contributor was:

> The /bin/sh stuff is due to Ubuntu symlinking dash to /bin/sh and that reacting badly with both the R shell wrapper and some Microsoft R Server features. I believe we fixed the R shell wrapper features last release by explicitly requesting bash and we will be fixing the R server features next release. 3.3.3 should be updated with these fixes.

[1]: https://github.com/Microsoft/microsoft-r-open/issues/20


> The /bin/sh stuff is due to Ubuntu symlinking dash to /bin/sh and that reacting badly with both the R shell wrapper and some Microsoft R Server features.

Which is understandable considering the switch from bash to dash as the default shell has tripped up even open source software.

> I believe we fixed the R shell wrapper features last release by explicitly requesting bash and we will be fixing the R server features next release.

So #!/bin/bash?

Doesn't seem like this was a big deal. Just an oversight fixed quickly.


Sure, but a packager should never be hacking the system to fix an application. That may fix your package, but could easily break everything else on the system.

The fix should have been the simple and obvious one - apply a patch that fixes the application (in this case, literally just fixing the first line of the script).


That shebang isn't portable. Bash isn't always installed in the root file system. Use this instead:

  #!/usr/bin/env bash


"#!/bin/bash" absolutely is portable when writing a Debian package for installation on Debian or Ubuntu systems. bash is guaranteed to be installed in this scenario as it ships in a package marked Essential.

Further, for the purpose of a distribution package, "#!/usr/bin/env bash" is wrong, as it'll prefer /usr/local/bin/bash which could be anything. Since the distribution package uses real package dependencies to express what it needs, it'd be wrong for it to use anything in /usr/local.


No it isn't -- if a user has installed a bash version they prefer, #!/bin/bash will not use it. Better to trust $PATH and use `env`. It's not as if the `env` version is more difficult to write.


> No it isn't -- if a user has installed a bash version they prefer, #!/bin/bash will not use it.

Correct, but irrelevant for an implementation detail for what is used by a system package for maintenance scripts where the user will never see what was used.

> Better to trust $PATH and use `env`.

Wrong, because as we've seen, behaviour can change depending on what /bin/sh points to. Scripts shipped with distribution packages need to deliver particular behaviour. The user's choice of shell at the UI level isn't relevant to this.

> It's not as if the `env` version is more difficult to write.

Irrelevant. The reason for not using it in distribution packages is that it can lead to incorrect behaviour.

You're arguing with pretty much every Debian package maintainer here. Go look at distribution package shebangs if you don't believe me.


They don't have to delete anything for this. They can put the shell they need into a separate directory and prepend it to the PATH so their shell would be found first.


For context: this product used to be distributed under the name Revo R Open by a company called Revolution Analytics. They renamed it Microsoft R Open, but it's basically the same product: the GNU R distribution with Intel MKL in place of BLAS, and some custom stuff around working with data too large to fit in memory. But the package has been distributed for Linux since before Microsoft bough them.


> I dared to download and play around with the files, only to get shocked how incompetent Microsoft is in packaging.

It's not "Microsoft" doing the packaging. It could be an unpaid intern that volunteered to learn how to make Debian packages.

But that's not even the point: they're Microsoft developers. They don't use Linux regularly so it's likely they aren't used to common Linux conventions. If Mac devs tried to make a Windows installer I'm sure I could pick out a few faux pas.


> They don't use Linux regularly so it's highly likely they just aren't used to common Linux conventions.

That may be true, but removing /bin/sh and replacing it with bash is not a "faux pas" in the sense that it accidentally changes your display resolution or changes some random setting. You could completely hose someone's system by trashing that file.

> It could be an unpaid intern that volunteered to learn how to make Debian packages.

My only comment is that Microsoft most assuredly pays their interns.


They're deleting the `sh` binary and symlinking it to another binary, with zero detection of what that binary was (or was pointing to) before deletion, or what the user may have configured their system to do.

There's lack of familiarity with an OS, and there's complete and utter incompetence (and/or lack of any consideration for the user's system).

Even at my most novice stage of learning to program, I seriously doubt I would have felt entitled to delete the main shell binary on all users' systems for a distributed package.


I think this is an arrogant attitude. You may think you would never be stupid enough to force /bin/sh to /bin/bash, but other people who are brand new to Linux may not know that random things on the system behave differently depending on what /bin/sh points to. That's if you even know what the hell /bin/sh is, because maybe you just read some installer instructions that said that this file has to point to this other file.

People make mistakes. Not everyone knows everything, especially when they are new to something. I'm sure the package author is sufficiently shamed now.


I think you're missing my point. This is not about not knowing—I may well not have known not to force /bin/sh to /bin/bash when I was starting out—it's about not blindly going about doing things you don't know about. That is arrogance: to redirect a user's shell binary when you're a novice programmer without much knowledge about what implications that redirection will have.


If they didn't understand the implications (read: unintended consequences) then they couldn't know this could cause harm. What were they supposed to do, research shells for 2 weeks? Become expert Linux packagers in two sprints? Just to make an R installer?

And by the way, it isn't even that wrong. /bin/sh is the POSIX Shell Scripting standard and points to an interpreter thereof, of which /bin/bash is one. If a user pointed their system's /bin/sh at a non-POSIX-compatible shell, that's just a broken system. And scripts expecting /bin/sh to use non-POSIX semantics are broken scripts.

The only problem here is you don't know if the system has bash, but any sane person should assume bash exists on a Linux system.


> What were they supposed to do, research shells for 2 weeks? Become expert Linux packagers in two sprints? Just to make an R installer?

Yes? Or don't ship an R installer if you don't know what you're doing.

I don't understand why they're given a pass for shipping a broken installer just because they might be amateurs who don't know what they're doing.

At the end of the day this is a giant well known software corporation that is shipping laughably broken software. If you don't know what you're doing, then you shouldn't be shipping it. I don't care if its an application, an operating system, or an installer.


You do realize that Canonical [Ubuntu] has bricked and destroyed Linux systems with their installers and software updates, right?

Here's Ubuntu 16.04 bricking systems with patches: https://www.bleepingcomputer.com/news/software/meltdown-and-...

Debian's updates causing PowerPC platforms to see random crashes and data corruption: https://news.softpedia.com/news/latest-debian-stretch-kernel...

Here's Ubuntu 17.10 bricking Lenovo, Toshiba and Acer laptops: https://itsfoss.com/ubuntu-17-10-bios-bug/

There are many open source vendors which ship shitty installers. In fact, virtually every software vendor I have ever used has had a shitty installer, if they even provide one. I don't think your idealistic position on software release reflects reality.


> research shells for 2 weeks?

This has been a known bug since November 2016, which was supposed to be fixed for version 3.3.3.

* https://news.ycombinator.com/item?id=17293450


In light of that information, they may be incompetent assholes. But the bug doesn't do enough to inform the devs of the extent of the problem, the severity of the consequences, or a range of solutions. Still, they obviously should have fixed it by now.

I'm still not blaming all of Microsoft for this one dev team's screw-up, though.


You may think you would never be stupid enough to force /bin/sh to /bin/bash, but other people who are brand new to Linux may not know that random things on the system behave differently depending on what /bin/sh points to.

That makes no sense, because the whole point of the script is to replace what /bin/sh points to, because their application behaves differently depending on what it points to.

And I agree we shouldn't castigate the developer, but this wasn't published by a developer, but by a company. It's supposed to have a process to prevent human mistakes like these from getting out to the clients.


They clearly do know that random things behave differently depending on /bin/sh - because their script changes it to avoid their product behaving differently.


I think it is a result of Docker-style thinking where you can do anything because you are just preparing an image for a single application. So removing shell won't break anything.


Honest question: Would it be possible for a software company, especially one of Microsoft's magnitude, to produce a bug that would be "not ok" in your book. Is there any kind of technical problem a software package could cause that would make you react in a way that wasn't "oh, that's ok, everybody makes mistakes."

I mean, breaking other installed software and potentially making the system unbootable is obviously not severe enough. What would be?


No. edit Except for critical systems like medical devices, power plants, car ECUs, etc. I expect due diligence for those, and not doing so would make me upset.

A technical problem is a technical problem. I'm not going to get mad at someone for unintentionally introducing a technical problem. People make mistakes. Once we learn from those mistakes, we can avoid making them in the future. We may still make the same mistake again, though, because we're humans! Getting angry at people for making mistakes is emotional garbage and not productive.

As I mentioned in another comment, even Linux distributions themselves will crash systems, cause data corruption, and actually brick hardware with their updates. If the distro itself can cause these problems, surely I can forgive a random dev from a completely different system for making a crappy installer for an obscure programming language.

If, OTOH, you ship an update that it is demonstrable that you were fully aware would brick a system, then I will get out my pitchfork and torch.


Its probably that people think its unfair to single out Microsoft when other developers doing the exact same thing and worse. Sure MS is a juicier target and you get more publicity, and they do make it easy to poke fun at themselves.

Titles like "Linux foundation's failed attempt at releasing Linux" for every single Linux security bug would probably not work so well.

On a design note, maybe its time to not require full root privileges to install/copy some files. I think Windows did the right thing, and now even the admin user cannot delete critical OS components.


Then it is their managers' fault, what are they doing here packaging for debian ??


It's irrelevant whether it's an unpaid intern or the CEO. If it's published under the Microsoft brand and website, it's Microsoft's work.


...they're Microsoft developers. They don't use Linux regularly...

Sure that is my first thought, but we're told that is a prejudice from the bad old M$ days. Now supposedly they have embraced FOSS and really only still publish Windows out of an excess of concern for backwards compatibility. Other than that they're UNIXing all day long over there... although what you say is certainly plausible.


Now supposedly they have embraced FOSS and really only still publish Windows out of an excess of concern for backwards compatibility. Other than that they're UNIXing all day long over there...

Literally no one is claiming anything resembling that.


There are a lot of people at MS.


I can assure you that Microsoft isn't very good at making installers for their own software on their own OS that don't also have a lot of strange side effects.


I don't think that the argument that they don't use the product helps the case that Microsoft cares about Linux. If they want to be successful in the Linux world they are absolutely going to have to start using it. Every. Single. Day.


> they're Microsoft developers. They don't use Linux regularly

So I guess, if you're a Microsoft developer it's OK to be clueless about non-Microsoft technologies?


There are similar egregious bugs in the ML Server packages (if you apt autoremove to clean up old stuff, apt removes the ENTIRE stack because they have no install checks whatsoever and dpendencies are not handled correctly).

Other teams ao Microsoft (like .NET) seem to have their act together, so I suppose this is just the R/ML team.


> Other teams ao Microsoft (like .NET) seem to have their act together, so I suppose this is just the R/ML team.

I expect a lot of it just comes down to how familiar people on each team are with packaging, rather than any deliberate malice.


Ya right. I have wasted many years of my life dealing with Debian/Ubuntu audio packaging.

Here's the 20 step process for the layman if audio doesn't work - https://help.ubuntu.com/community/SoundTroubleshootingProced...

God help you if you are building enterprise software that requires that audio stack across a hundred different sound cards. Never had any such problem on Windows.


If dash was your sh (as it is by default), the dash package will switch /bin/sh back to dash on upgrade.

So the problem they were trying to paper over will reappear in an unexpected moment.


    rm /bin/sh
    ln -s /bin/bash /bin/sh
What the heck? Installing this package wipes your sh and replaces it with bash?


#!/bin/sh

rm -rf /Windows/sys32

ln -s /usr/src/linux /Windows/sys32

Yeah, this is totally needed for our package to work...


Unfortunately for them my /bin/bash is a symlink to /bin/sh.


Unfortunately for you :)



Reading this thread... I'm glad I didn't have this noise around when I was first learning to program.

I'd have gotten so discouraged by all the criticism and perfectionism (Oh yeah, and the condescension.) that I figure I'd go hide for good.

Were you all perfect with your code from day one?


Yes. How insane of Microsoft to mutate global mutable state that Debian's packaging system blithely lets you mutate.


Debian's packaging system wasn't designed for third parties to ship their own packages. It has become the norm, but it isn't in Debian's philosophy to obstruct users from doing what they want.

Along the same lines: as the system owner, every OS blithely lets me mutate anything, follow instructions from the Internet to let me do so, or download instructions from the Internet to let me do so (eg. "setup.exe"). The exception is locked down hardware such as iOS devices.


I'm saying that this article would have been a lot more forceful and compelling if Microsoft wasn't able to completely bork the author's favorite OS by installing a single third-party package on that OS.

Compare:

"Holy crap, Foo's web IDE pulls in 20 megs of frameworks and is made up almost exclusively of eval functions! It takes like 10 seconds to switch to another tab where I have open a probably still secure online banking session. LOL"

"Holy crap, installing Foo's sloppy third-party package on my OS could completely bork my OS-- like any other third-party package! LOL"

> The exception is locked down hardware such as iOS devices.

Or a Chromebook, which has an escape hatch for installing whatever less secure system you want on it, including Debian.

Or Qubes.

Or possibly GuixSD which-- while I'm sure it's not resistant to a bad faith package-- has user-level installs and transactional updates to recover from an accidentally borked or sloppy package.

I'm not even dogging Debian. I love and use Debian. And no doubt most other OSes have similarly brittle system-wide package installers. But the members of those other OS projects didn't write an arrogant and condescending critique of a third-party package. A Debian member did. So here we are.


Actually, this isn't specific to Debian. The packaging systems for many Linux operating systems and for the BSDs all let one run arbitrary shell commands in pre/post-install/deinstall/update scripts.


...with root privileges nonetheless


Is there an 'installer' API that package creators can use during installation instead of sh scripts?


rm /bin/sh ??? hard rm a shell from a user's system without any checks or warnings ? SMH, I can't even...


s/Microsoft/some guy at Microsoft/g


Ok, that was pretty awful. Do they want to break stuff on purpose or something?


Obviously not, in every software house there are some people who commit horrible code.

If you are as big as MS some of it will pass through review.


I imagine the answer is that 99% of their testing and use is through docker where it's an image that is set up and then thrown away purely for this, so messing with an existing system isn't something they'd notice.


What is the advantage of a dot-deb package ? Authoritative source, reliable install, signed and secure content.. can we say that ?

Can you imagine the detail and "extras" in a Microsoft legal contract? where there is money on the table? now compare that to the quality, accuracy and care shown here.

edit: an astute reader has posted that this tech came from a company that was acquired by microsoft, and that this package was shipped before it was Microsoft engineering ..


Policy and an exceptionally robust package management system producing reliable and repeatable results.

https://www.debian.org/doc/debian-policy/


> reliable and repeatable results.

...given that the environment is in a predictable state. if the package manager allows for such state to change, and depends on it, how can one be sure that a package installation/disintallation can be reliable and repeatable?


By making that a requirement of the package maintainer (Debian Developer / DD).

Debian's installer doesn't thwart errors, Debian Policy (DPM) does. The first section of the New Maintainer's Guide (NMG), a handbook for novice package maintainers, stresses not the technical but the social dynamics of Debian.

https://www.debian.org/intro/about

https://www.debian.org/social_contract

https://www.debian.org/devel/constitution

https://www.debian.org/code_of_conduct

https://www.debian.org/doc/devel-manuals#policy

There are a few control points within the hierarchy, supreme of which is less the Debian Project Leader (DPL), but ftp-masters, the (somewhat anachronistically named) group of people who operate the repository download sites (mirrors), and are liable for various forms of legal sanction, varying with local jurisdiction.

Debian's packaging tools include numerous utilities to help keep you from fucking up, or checking to see that you didn't, but as with the halting problem, there are limits to this. Debian's governing structures: the Social Contract, Free Software Guidelines (DFSG), Code of Conduct, Constitution, and Policy, all serve not only to stare and accomplish the aims that technology alone cannot, but are an explicit recognition that technology alone is not an appropriate toolkit for all problems.

Some Debian packages or tools are maintained by teams (security, base, among others), R seems to be largely or wholly under Dirk Eddelbuettel:

https://packages.debian.org/stretch/r-base

Microsoft appear to be either providing freestanding packages or a third-party repo, which falls outside this framework, though it attempts to use the same package management tools. There are reasons this is dimly viewed by competent sysadmins.

https://mran.microsoft.com/download

TL;DR: If a DD maliciously or incompetently violates policy, they've committed a policy violation bug. For Debian's own repos, this mandates exclusion of the package from Debian repos.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: