You can see the contents of a package in Debian's package site, you have to go to the available architectures of a package and select the list of files for the one you want
You can also search contents of packages if you select the option in search (the other options are package name, description)
For one, packages.ubuntu.com throws errors or is down all the time. (I got an Internal Server Error just now).
The usability of searching "package directories" vs "the contents of packages", having to toggle between package names vs "source package names" vs descriptions, and choosing substring matching modes is... well, very typically Linux.
1. The naming is confusing, a web interface that lets you browse a particular database is not generally called "a web browser" for that database. A web browser is the actual software you use to access the web.
2. I searched for a (not so) random package [1] and quickly got a bunch of matches. I did not understand the ordering (the latest version number was not on top).
3. When I clicked the first match, I got a "Bad Gateway" error from [2], but I guess it might be squeezed by HN just now.
Regarding 3, It seems like its related to package size. Openssh-server has the same problem [3]. Was also looking at some moderately sized packages and it was struggling but would eventually return the page. Smaller packages seem to be no problem.
(BTW, I really wish projects wouldn't have unnecessary codenames. Search engines could deal with people searching for "foosoftware 11" rather than "barcodename". Now we have to memorize numerous codenames for one thing, and frequently translate back and forth between codenames and the actual name and version number.)
I have used https://pkgs.org/ for years, which has many more distros, includes popular third-party repos like EPEL, and lets you filter to distro or package type you're interested in.
pkgs.org doesn't seem to let you inspect the contents of the files in the packages (unless I missed it). I guess that's what the APT Browse thing does but it doesn't seem to be working for me at the moment.
Back in 2016, when I was exploring Linux for the first time, one of my favorite commands was "apt-cache search <keywords>." It performs a grep on package descriptions, and I discovered many fascinating things this way.
Fun fact, deb packages are just ar files with a funky header (d.e.b) and some pre/post scripts. Ar files are also .o files after compilation but before linking, what!?! Also, tar is based on Ar, WHAT!?! Elf files, the whole thing is standardized! WHAAAT!?!
The quick mention of the LSB spec led me to this fun Wikipedia page[0]. Apparently Red Hat once wanted to force Linux distros to accept gzipped RPM packages, as well as demand that things like CUPS were always installed. Attempts to comply with it were pretty much non-existent outside of the still used legacy lsb_release command and its associated configuration file, since Red Hat had apparently never actually considered whether or not anyone wanted to comply with it.
The entire thing is an ISO spec even, which is kinda baffling. Deprecation was also a mess, with it initially only being possible to remove things from the spec 3 major versions after the specs release (only for that to be violated with version 4.0->4.1 where they removed Java as an optional module that was required to be LSB compliant).
The entire thing went bust in 2015 due to lack of interest.
Lovecraftian horror as a file format. What a great article.
I had a look at when this article was posted on HN a few years ago. The comments are typical nitpicky HN comments like "but why did he want to make his own implementation" or "he didn't have to understand the file format, just use rpmbuild". How disappointing. As if half the stuff on HN isn't understanding/analysing obscure interesting crap that nobody outside of tech would ever care about.
It makes more sense if you realize that for a good lot of tech, the goal was not to create a better tech. Even if they happen to say so. It's just people wanting to go ahead, to do their own thing, to make money, be famous, be the one that created a thing. Learning from the past is orthogonal to these goals.
Fun fact, deb packages are just ar files with a funky header, containing a "debian-binary" file containing the deb version (nowadays 2.0), and two compressed tar files, control.tar.$comp and data.tar.$comp, where $comp can be gz, xz, or whatever else is supported.
It's very helpful when I stare at a file and thinking, "WTF this file doing there?". These two commands help me immediately: `rpm -qif file` to show description of file package, `rpm -qlf file` to show list of other files in the same package.
48 comments
[ 3.0 ms ] story [ 98.9 ms ] threadI prefer the search on the original sites, but this looks neat if you want the payload of a package.
Compare:
https://sources.debian.org/src/htop/2.0.2-1/
https://www.apt-browse.org/browse/debian/stretch/main/amd64/...
You can also search contents of packages if you select the option in search (the other options are package name, description)
For example https://tracker.debian.org/pkg/curl
The usability of searching "package directories" vs "the contents of packages", having to toggle between package names vs "source package names" vs descriptions, and choosing substring matching modes is... well, very typically Linux.
1. The naming is confusing, a web interface that lets you browse a particular database is not generally called "a web browser" for that database. A web browser is the actual software you use to access the web.
2. I searched for a (not so) random package [1] and quickly got a bunch of matches. I did not understand the ordering (the latest version number was not on top).
3. When I clicked the first match, I got a "Bad Gateway" error from [2], but I guess it might be squeezed by HN just now.
[1]: https://www.apt-browse.org/search/?query=gentoo
[2]: https://www.apt-browse.org/browse/debian/jessie/main/amd64/g...
[3]: https://www.apt-browse.org/browse/debian/stretch/main/amd64/...
doesn't seem to be finding `firefox-esr` in current Debian Stable:
https://packages.debian.org/bullseye/firefox-esr
Also note that there are security updates to the version in bullseye:
https://tracker.debian.org/pkg/firefox-esr
(BTW, I really wish projects wouldn't have unnecessary codenames. Search engines could deal with people searching for "foosoftware 11" rather than "barcodename". Now we have to memorize numerous codenames for one thing, and frequently translate back and forth between codenames and the actual name and version number.)
https://en.wikipedia.org/wiki/Ar_(Unix)
We all have much to learn from the past tech, yet we ignore and re-invent the same problems over and over again, proverbially walking in circles.
BTW, while the parent is technically correct, .deb files can contain much more features and magic than that.
Yes, we certainly can't forget shell archives.
https://xyrillian.de/thoughts/posts/argh-pm.html
The entire thing is an ISO spec even, which is kinda baffling. Deprecation was also a mess, with it initially only being possible to remove things from the spec 3 major versions after the specs release (only for that to be violated with version 4.0->4.1 where they removed Java as an optional module that was required to be LSB compliant).
The entire thing went bust in 2015 due to lack of interest.
[0]: https://en.wikipedia.org/wiki/Linux_Standard_Base
I had a look at when this article was posted on HN a few years ago. The comments are typical nitpicky HN comments like "but why did he want to make his own implementation" or "he didn't have to understand the file format, just use rpmbuild". How disappointing. As if half the stuff on HN isn't understanding/analysing obscure interesting crap that nobody outside of tech would ever care about.
You need to populate a few files with certain values but apart from that it is just tar and ar.
To do the reverse: I provide a file path and you can determine in which package(s) it is present.
https://askubuntu.com/questions/481/how-do-i-find-the-packag...
It's very helpful when I stare at a file and thinking, "WTF this file doing there?". These two commands help me immediately: `rpm -qif file` to show description of file package, `rpm -qlf file` to show list of other files in the same package.
Have fun :)