Apt 2.0
blog.jak-linux.org
blog.jak-linux.org
Seems like a pretty big breaking change.
I would suggest reading the apt-pattern man page referenced before passing judgement.
I am sorry but this isn't true. I can prove it.
Regex is used to parse the program itself that runs APT, this is called Lexical analysis[1]. GNU Bison and Flex [2] are lexical analyzers for example that compile a lot of code we write today. So whatever pattern matching code was written in C as part of the APT 2.0 package, that code itself is read and compiled by regex. So, it provably cannot be impossible to do a match using this new feature you're referring to that cannot be matched using plain old regex. Difficulty is subjective depending on who the target demographic is.
All these things are actually moot - it doesn't cost you anything to keep Regex option to search for some package names, perhaps a bit of additional code to maintain. Also, other means of pattern matching can be added in addition to regex search feature. Why not both?
[1] https://en.wikipedia.org/wiki/Lexical_analysis [2] https://aquamentus.com/flex_bison.html
glob style wildcards are more common, though, in that context, anyway. It would be safe to re-enable those, but I'm not certain this provides a sensible user experience improvement.
`WARNING: apt does not have a stable CLI interface. Use with caution in scripts.`
So I think the trust model bears scoping. It's not all or nothing.
As it happens, Debian itself kinda does this (Debian "maintainers" can only upload to specific package names), but I don't think anyone else runs that software. The usual third-party repo tools like reprepro and aptly don't support it, as far as I know. And sites like Launchpad or OBS just set up a separate apt repo per account (or even multiple apt repos per account), because doing that is very easy.
In other words - yes, the trust model you propose is coherent, but I don't think anyone actually does that, because there's a more straightforward option already.
But this is hard to do correctly for deb repositories. We first need to come up with a way to declare repository groups so you can say that e.g. the security repo can provide updates to the main repo.
apt has had support for pdiff for what, two decades now?
https://debian-administration.org/article/439/Avoiding_slow_...
I am no fan of it though, dnf is just so much better in all respects.
I remember checking their packaging howto every few years to maybe really/properly/truly understand it, but just the sheer uselessness of the text signaled each time that it's just not worth it. Just google whatever you want copy from stackoverflow, and be done with it, don't try to understand it. (Eg. if I wanted a virtual package that provides some package so I can fake that so it won't get pulled in as useless dependency for other packages.)
What you're seeing here is some hook that's being run and updating its cache.
~# time apt update
real 0m5.059s
real 0m4.981s
Okay, adding Focal 20.04 LTS repo. apt install -y apt, got apt 1.9.10.
real 0m7.222s
real 0m6.924s
It fetches the InRelease files, all of them seem to have an ETag header, but probably Apt doesn't feel that it can rely on those for some reason.
But using `apt -o Debug::Acquire::http=on update` we see that it depends on the "If-Modified-Since" request headers. And many of the repos just return 304.
There doesn't seem to be a config setting for increasing the number of outgoing connections either.
So even if it gets just 304 responses it still does the "Reading package lists... Building dependency tree" part, which is slooow.
In some cases, shedding requirements is good. In most, it is just a race to feature parity. :(
RPM is a solid, mature, heavily used package format. And the .spec file I've always found to be so much easier to work with than Debian packaging. I've made many debs, and my current work uses debs for deploying all our software, but I still find it so much harder to make them. I have a workflow for my current packages, but if I want to take a new piece of software and turn it into a .deb, it is always pretty painful. I usually have to ask a debian packager for help. They are always super nice and helpful, but I just wish I could package things myself.
Seems like if you package .debs all the time, it becomes easier. But as an infrequent packager, I find RPMs .spec to be much easier to manage than Debian's system.
Ports systems like alpine/arch/void are nice, but they also handle less (except for void maybe, that ports system has built in support for a lot of different build systems, so packaging a cmake or meson project is a breeze).
It's actually possible to use RPM spec files to build Debian packages: https://github.com/debbuild/debbuild
And I've been going through and slowly porting much of the RPM ecosystem common macros to run on debbuild so that spec files can be reused to comply with Debian packaging policies as much as possible: https://github.com/debbuild/debbuild-macros
(Disclosure: I'm the current maintainer of debbuild)
Be aware that high parallelisation of downloads may reduce your throughput for small number of things to fetch.
There also should be no latency need - APT keeps the number of requests it has sent to the server at 10, so there should be no latency overhead. Yes I know, this does not work for Google because their latency is crazy high, but their speed is super high too.
Does anybody know if there are plans to fix the .deb size limit? It's a bummer that .debs can't be more than 10 GB. That number seems big, but I've hit it before when packaging custom toolchains for internal use at my company.
I was working on trying to package Xilinx Vivado for internal use on my company's build servers. It's around a 20-25GB installation, mostly of smallish files. I could have definitely manually split the package up. It's the kind of thing that's hard to do algorithmically though. After a day or so of trying to solve the packaging problem, I eventually gave up on the idea altogether.
Large software installs are still fairly uncommon on Linux, but I see more and more of them in the wild. Especially when I look at some games and stuff - I have a bunch of software that's larger than 10 GB. It's kind of nuts that the .deb package format is still so constrained, especially considering its importance to so many distros.
But then with deltas, mirror sizes grows even more, which is a hard sell.
Arch Linux gets away with using zstd -21 but that's not practical for general purpose Linux distributions, as it has significant memory requirements compared to xz.
Also the speedup in practice is negligent - while zstd is much faster than xz, most of the time installing packages is actually spent in fsync(). So you only see huge speedups when run in eatmydata.
Decompressing -21 requires 20MB vs 10MB for -19 and xz.
https://lists.ubuntu.com/archives/ubuntu-devel/2018-March/04...
You can see that the performance gain from zstd under realistic scenarios is about 10%.
you can see that switching from xz to zstd only improved firefox install time from 37s to 33s; running in eatmydata to avoid fsync from dpkg improved it to 12.5s (8.5s with zstd).
I don't know what Arch linux does, but they likely do not correctly fsync() data after its been written to a temporary file, and then fsync the directory after files have been renamed to their final names, as is required to achieve consistent results in a crash.
I feel like once people got used to patterns, that will be sufficient though, and the error reporting gets nicer.