APT Browse: A web browser for the contents of Debian (and Ubuntu) packages(apt-browse.org)
apt-browse.org
APT Browse: A web browser for the contents of Debian (and Ubuntu) packages
https://www.apt-browse.org/
48 コメント
...and younger generations think that the older tech and file formats are just incapable piles of bytes put together haphazardly.
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.
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.
The rpm file format is indeed a pile of bytes put together haphazardly.
https://xyrillian.de/thoughts/posts/argh-pm.html
https://xyrillian.de/thoughts/posts/argh-pm.html
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.
[0]: https://en.wikipedia.org/wiki/Linux_Standard_Base
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
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.
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.
> We all have much to learn from the past tech
Yes, we certainly can't forget shell archives.
Yes, we certainly can't forget shell archives.
trying not to completely blow their mind. Keeping it simple, describing it just as an archive.
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.
devil in the details. But yes, you are correct. There are archives of archives in the archive. :insert Keanu whoa:
I think bookworm is going to support zstd, or at least `tar` will.
Once I made myself a little script to build Deb packages using only basic tools: https://github.com/qznc/simpledeb/blob/master/simpledeb#L61
You need to populate a few files with certain values but apart from that it is just tar and ar.
You need to populate a few files with certain values but apart from that it is just tar and ar.
I wasn't expecting my world to be thrown so hard from reading HN comments today, but here we are...
It's interesting to note that tar files have no checksum/crc, the .gz compression takes care of that.
The tar format was originally intended to be written to tape.
Quite neat, but I had two problems:
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...
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...
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.
[3]: https://www.apt-browse.org/browse/debian/stretch/main/amd64/...
[3]: https://www.apt-browse.org/browse/debian/stretch/main/amd64/...
Also I clearly had problems counting all the way to two. Darnit.
What's wrong with https://packages.debian.org/ and https://packages.ubuntu.com/ ?
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.
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.
It seems to put lore focus on the extracted dpkg. So you can browse and download the unpacked files.
I prefer the search on the original sites, but this looks neat if you want the payload of a package.
I prefer the search on the original sites, but this looks neat if you want the payload of a package.
In that case, what's wrong with https://sources.debian.org (other than people apparently not being aware of it)?
sources.debian.org has the source for the package. apt-browse.org has the files that are installed by the package.
Compare:
https://sources.debian.org/src/htop/2.0.2-1/
https://www.apt-browse.org/browse/debian/stretch/main/amd64/...
Compare:
https://sources.debian.org/src/htop/2.0.2-1/
https://www.apt-browse.org/browse/debian/stretch/main/amd64/...
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)
You can also search contents of packages if you select the option in search (the other options are package name, description)
The tracker is even better imo
For example https://tracker.debian.org/pkg/curl
For example https://tracker.debian.org/pkg/curl
Also apt-file so you don't have to leave the terminal
[deleted]
[deleted]
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.
But why "newest" Debian release is 9.x (Stretch) released in 2017 (current alias "oldoldstable") ?
And the latest Ubuntu appears to be bionic (18.04).
https://www.apt-browse.org/search/?query=firefox-esr
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.)
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.)
The worst ones are Intel code names. I cannot remember one from the other.
You know what would be nice?
To do the reverse: I provide a file path and you can determine in which package(s) it is present.
To do the reverse: I provide a file path and you can determine in which package(s) it is present.
On rpm-based systems: `rpm -qf /path/to/file`.
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.
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.
dpkg -S /your/path
Have fun :)
Have fun :)
dpkg or apt-file can do this from the command line. Or you can use https://packages.ubuntu.com/
https://askubuntu.com/questions/481/how-do-i-find-the-packag...
https://askubuntu.com/questions/481/how-do-i-find-the-packag...
DNF as well with “dnf provides <filename>”
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.
[deleted]
Does anyone use this regularly? What situations would it be useful in?
how is this different / "better" than apt-file?
https://en.wikipedia.org/wiki/Ar_(Unix)