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.

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

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.

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

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

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.

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!

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

    # 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}

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

* 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

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.

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.

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.

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

Search also Jordan Peterson on how to tickle a baby.

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.)

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...)

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