Sysinternals / ProcMon-for-Linux

Procmon is a Linux reimagining of the classic Procmon tool from the Sysinternals suite of tools for Windows. Procmon provides a convenient and efficient way for Linux developers to trace the syscall activity on the system.
MIT License
4k stars 259 forks source link

Package it in Debian #24

Closed vanillajonathan closed 2 years ago

vanillajonathan commented 4 years ago

Package ProcMon and make it available in the Debian package repositories.

asdf8dfafjk commented 4 years ago

Also, "please" make a dvd and personally present it at vanillajohnsons house.

lucypol commented 4 years ago

https://github.com/microsoft/ProcMon-for-Linux/blob/main/INSTALL.md

wget -q https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb

Why wait?

No need to suck on distro package repos, you can add upstream as additional sources

The problem with distro repos is they are notouriously out of date and not official from the developer

I would prefer this be pushed out by Microsoft's own repo and not having to rely on distro repos, I prefer to pull direct from upstream

Please add it to Microsoft's own upstream repository for additional source adding

Anyway, you're creating the issue in the wrong github, you want to create this in the distro github, what distro maintainers do is up to them (and their users)

vanillajonathan commented 4 years ago

Because it is easier to just be able to install things directly without having to add third-party sources for each piece of software.

lucypol commented 4 years ago

Because it is easier to just be able to install things directly without having to add third-party sources for each piece of software.

So take it up with the distro maintainer, go to their github

If you are too lazy to even manage a single line in a file for a source direct from the developer, you don't belong on Linux, it's not for you, distro maintainers are notouriously out of date and lag behind

In case you missed it, this tool is OPEN SOURCE, it already is AVAILABLE to the distro maintainers (and it is a debian package for apt)

It is up to the distro maintainer to do their thing, nobody else, it is their distro, nobody elses, upstream is not responisbile for downstream repos, those are maintained by whomever owns them

Another big shocker for you, you can even manage your own repo with .deb files (and AppImages and Flatpak or whatever) locally on a NAS with web/ftp server on it then point that to your own alternative sources (or a flatpak source) and voala, you have it directly installed.

Zocker1999NET commented 4 years ago

TL;DR: It would be great if the maintainers of this repository could add their /debian directory to this repository as the maintainers may are already managing one and this may could be reused for Debian/Ubuntu maintainers without further adaptions.

@lucypol I see your point too, the packaging itself is the task of the distro maintainers, also because sometimes adaptions to other packages or the distro are required. But because of these adaptions, I also prefer the solution to use packages from the distro repos as required patches or adaptions are written once for all. But this being "easier" for user also means more secure (you only trust one party, and to verify this single party is trustworthy is more easier than verify the trustworthiness for multiple parties). What most people do not know, if you add an additional upstream repository along with its GPG key (that is what the package packages-microsoft-prod.deb does) and do not configure apt preferences to ignore other packages from this upstream, the upstream could present any package (like libc) verified with its key to your system and it would accept it as you choose to trust this upstream repository. I do not think that big players like Microsoft will choose to do this, however it may be more easier for hackers to upload malicious packages to their upstream instead of to the repository of Debian. Also, if the key will be compromised, you should know about because then such attacks are possible until you remove the key from your system. I know, that these problems can also happen to the distro I'm running, but it still is an additional risk I'm not willing to take on most of my machines. Also mechanics like apt caches and repository snapshots do work out of the box without further adaptions like including the repository of Microsoft (in this case). Managing your own repo (not cache), at least in my eyes, creates an even bigger overhead than upload it to distro repos as everyone is required to do additional, required work on its own.

It will help if a shared /debian directory could be managed in this repository, so maintainers of Debian and Ubuntu could use this as a common base for uploading the package into the distro repos. I think the maintainers are already managing the metadata required for package building inside the /debian directory (because the are uploading .deb packages). So it should be easy to add this one to this repository, too.

jdrch commented 4 years ago

https://github.com/microsoft/ProcMon-for-Linux/blob/main/INSTALL.md

wget -q https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb

That actually doesn't work on Debian Buster, because the .deb isn't packaged in Debian format.

asalmela commented 3 years ago

Intent to package has been filed at Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965242

jahabibi commented 3 years ago

Related issue #70.

MarioHewardt commented 2 years ago

Duplicate of issue #70