| > Additionally, by the time I started messing with RPM packaging, I had already packaged for Gentoo, Arch, and Ubuntu, so I think I had already developed some intuitions for how to explore packaging systems and their documentation. Ah, that might have helped I suppose. I haven’t done any sort of packaging in the past so that might have not helped. > but all of those were added to pacman within 2 or 3 years of when I stopped daily driving Arch-based distros. Ah, that would explain why I hadn’t experienced that myself, having only switched to Arch about a year ago now. > it only examines version constraints for new stuff or updates it's grabbing from the repo. This is part of why 'partial upgrades' aren't supported and all of why your AUR-installed packages are liable to break after `pacman -Syu`, requiring sane AUR wrappers to rebuild your AUR packages after each system upgrade. Isn’t this, while being slightly inflexible, reasonably logical with Arch being rolling release? I was under the impression that you weren’t supposed to upgrade anything individually, as that upgrade might cause the need for a newer version of some dependency, which could break other packages. > make it easy to tell when an upgrade or installation might require you to change the 'supplier' of a given package This has worked fine for me with packages installed from the AUR (through yay), although I can’t think of any examples, but I think it’s only happened once or twice. > Honestly I should probably try running Arch again for a while to help update what I think of pacman. I would recommend that you do, as Arch is the best distribution ever! :P Thanks for sharing that information, as I’ve never heard anyone talking about pacman at that time, so I’d assumed it was always like it is now. It was very enlightening. |