Tweet
If I might I ask a question about all these package managers; do ANY of them have any sort of installed package tracking and version roll-back features? And if not, why not? Is it very difficult to implement? Seems to me it should be a default considering the rolling nature of some distro's which can be easily wrecked if something slips by.
-
Hi -
From what I understand, installed package tracking is universal.Originally posted by stiiixy View Post
Version roll-back is not common because it makes dependency management more complex and requires the application developer to write downgrade pre and post scripts as well as the normal upgrade pre and post scripts. If I want to rollback a library XYZ from version 1.0.2 to 1.0.1, I have to roll back every every piece of software that uses XYZ to a version that is compatible with 1.0.1. In turn, I have to roll back every piece of software that uses those libraries too. So if I have library ABC that relies on XYZ I would need to downgrade that. etc... And further, I need to write downgrade scripts for the reverse update process. So if the update for package XYZ from version 1.0.1 to 1.0.2 changes the configuration file line "this=that" to "this=these", then the downgrade for XYZ from 1.0.2 to 1.0.1 has to handle changing "this=these" back to "this=that", or else the software won't work properly. That's not a big deal if I'm just changing one line in a configuration file, but for some software upgrades there are complex steps involved and writing the code to reverse those steps makes a lot more work for the person creating the package.
It's more common to use version pinning, which APT, YUM, and XBPS support. If you know that you don't want to upgrade from Java 7 to Java 8, you can pin your Java installation to version 7. Then your Java version never gets upgraded, and anything that depends upon Java never gets upgraded. So instead of supporting downgrades, you just stop the upgrade from happening. That's easier to support - but of course it's less useful, because you have to know to pin a package before the upgrade does something bad, and if you do the upgrade by accident you're stuck.
And YUM and the lesser known Nix and Conary package managers support snapshot rollbacks. If your system worked well on September 3 and is broken by an update on September 4, you can roll back everything to exactly how it was on September 3. Nix and Conary support that by default, it's a feature you have to enable with Yum (same page as I linked to before, http://blog.chris.tylers.info/index....on-Fedora.html ). Apt and XBPS don't support system snapshot downgrades at all. But either way, this kind of downgrade is system-wide - you pick a target date, and every package on your system is downgraded to the state it was in at that date. Then you can pin the package or packages that broke, and upgrade the rest. So that's incredibly useful.
(Edit) Having said all of that, I've been using Linux pretty frequently for over ten years and I've almost never had a software package update break anything for me. When it does happen, it's a real headache, but it's relatively rare. The only time it did happen to me, it was over a Java upgrade. I use Java for work and one of our tools does runtime manipulation of Java `compiled` bytecode. The tool that did the runtime manipulation only knew how to handle Java bytecode compiled with Java 1 to Java 6, so our software broke on the upgrade to Java 7. It took me a while to put my developer workstation back into working order.Comment
-
So what makes this different then Arch Linux?
Void uses the same PKGBUILD source files, xbps seems to work the same as makepkg.
What a bullshit Distro.Comment
-
Well I'll be damned. Thanks for posting that, I had never read about pacman before. I have pretty expensive experience with Debian derivatives and Red Hat derivatives, but I never took a Linux distribution in the Arch family for a spin. I just posted a question to the Void Linux Google Plus page asking the author to comment on XBPS vs. pacman. I took a tour through the Arch Linux wiki pages for pacman, and it appears to offer more or less the exact same set of features as XBPS.Originally posted by cryptoahash View Post
If he's just repackaging Arch packages, I'll be extremely disappointed.
Also, pacman is GPLv2+, XBPS is 2-clause BSD. I'm a closet FSF bigot, I prefer the former to the latter. So if he can't extensively justify the technical differences between XBPS/pacman and Void/Arch, I'll switch to Arch.Comment
-
Comment
-
Originally posted by Michael_S View Post
Thanks for that. Guess I was (yet again) oversimplifying the process in my head down to one point when it's more than that.HiComment
-
-
I asked on the Void Google Plus Community, https://plus.google.com/u/0/+Michael...QQhvgVA?cfem=1Originally posted by cryptoahash View Post
Response quoted (I don't think that's a violation of terms of service, but if it is, please delete the quoted text or ask me to do it.)Differences:
- XBPS code is totally written by me, the exception are some parts from NetBSD and OpenBSD; any code is 2 or 3 clause BSD. No GPL code involved.
- XBPS contains a lot more of pkg metadata than pacman, locally and in the repository index: required shared libraries, provided shared libraries, dependencies, build date, sha256 hash of the binary package, etc.
-XBPS has fewer dependencies than pacman: just needs zlib, openssl and libarchive. Compare this to pacman, where they need curl and gpgme thath depend on more external libraries.
- XBPS has supported SHA256 hashes for binary packages and pkg files for years! pacman recently added mtree support.
Technically there are not many differences between them, but I want to state clearly that both are system package managers, they don't allow multiple versions of a pkg installed, unless the files don't conflict. This is also true for dpkg, rpm, and others. Nix is not on this category.
Now xbps-src/xbps-packages:
- xbps-src and xbps-packages have been written from scratch by me, this is not a PKGBUILD conversion. Check the commit logs to see what I'm talking about. And I've lost 5 years of my life on it, 95% completely alone.
- xbps-src has supported sub packages for years, long before makepkg had support...
- xbps-src supports cross compilation for multiple targets. makepkg can't.
- xbps-src builds pkgs in linux containers BY DEFAULT.
- xbps-src supports build options.
- xbps-src allows you to build your own distribution FROM SCRATCH, NO ADDITIONAL BINARY PACKAGES INVOLVED IN THIS PROCESS.
And a lot more that I don't care about.
PS: The git repositories contain all commit logs since 2008 when I started, if you are curious how it progressed don't be afraid.Comment
-
What threw me off is that both 'pacman' and 'xbps-install' use the input flag '-Syu' for downloading and installing all available package updates. That immediately made me suspicious that XBPS is a ripoff of pacman.
But I looked at the rest of the input flags between the two of them, and besides '-s' for search they use different options.
Those differences, combined with the feature differences I quoted in the previous piece, make me believe it's not just a Arch ripoff.Comment
-
Sorry to keep bombing the thread, I tried to edit the previous post to add detail but ran out of time.
'-Syu' means Sync (S), assume yes (y), update (u), so it's a reasonable mnemonic for both packaging systems.
The package files also have some identical keywords, like "pkgname" but most of the keywords are different with some overlap but some key differences. For example, Arch includes target architectures in the package, XBPS does not. Pacman notes the maintainer in the package comments, XBPS stores it as one of the fields in the package database. Pacman stores multiple sha256sums for packages, XBPS stores one. etc... etc... It can't be a direct knockoff, the differences are significant.Comment
Comment