How to manage "forks" of official packages?

Question

I'm trying to figure out a way to use a custom repository to track packages I copy from ABS and modify. Creating the packages, and the repo DB, is easy. I just can't figure out how to sanely USE such a repository.
What I'd like to emulate is a "highest version wins regardless of source repo" behavior, and I know pacman doesn't do this. I want name collisions of packages to resolve to my repo when myversion <= officialversion, and use the official package otherwise.
The value of this behavior would be that pacman alerts me (by nominating for upgrade) when the official package is updated and my modified version is thus out of date. Then, I cancel the pacman upgrade and go update my personal repo instead.
If I put my repo first in pacman.conf, I can't track the official versions of the modified packages. If I put it last, my repo adds no value over not having a personal repo at all and just doing "pacman -U" on the individual packages (which is what I'm doing now).
I want to make it clear that I'm NOT complaining about pacman's behavior, or asking for a change. I think rather that I'm going about this the wrong way, and so I'd like to know how others have solved this problem.
(This thread is also related to my "which official packages do you modify?" thread, in which I try to determine how important this problem is to other users.)

Answer 1

ataraxia wrote:
So, it's taken me a while to write a reply to this thread. I had the problem that when I saw the suggestions, I immediately didn't like them. It's taken me 3 days to figure out why not, and I felt that I'd better have a good reason before I reject the advice of both a pacman developer and a repo maintainer on this subject I do appreciate the replies, and I don't want to look like a jerk.
My feeling is basically that these answers don't make any improvement over what I've been doing -  just not having my custom packages in a repo at all, but installing them with pacman -U. Adding shell scripts to my system is not very KISS. I'm a sysadmin by trade, and if there's one thing I've learned, it's to use as few tools as possible. This is why I avoid quality software like rebase, reflector, powerpill, and yaourt - great stuff, but I can get by without them. (Naturally, Xyne, being the author of several of those examples, probably doesn't subscribe to this philosophy.)
What a jer...
ataraxia wrote:I wonder if I'm suffering from the XY problem here. I don't really want to use a personal repo to solve this problem (in fact I'd prefer to avoid it for the complexity it represents) - I just want to be able to fork official PKGBUILDs in a way that's lightweight, flexible, and scalable, and I saw a personal repo as a good shot at success. Perhaps readers of this thread could tell me how they handle this problem? I'm basically looking for methodology, not helper-tools.
My understanding is that you want to maintain custom versions of repo packages in the same release cycle. You also want to achieve this without using simple tools (or, by extension of your KISS argument, complex tools) and in the simplest way possible. I see that as a contradiction.
Even considering the XY problem, your original post suggested a willingness to accept a fair amount of complexity so it seems strange that you would reject a very simple script to achieve your goal. If doing it all manually is undesirable but using a script is unacceptable then I don't see a solution.
There's an unavoidable (if small) level of complexity involved in what you want to do. Unless you have figured out a way to automate building the custom packages with each new release with whatever changes you've made (which would certainly require complex tools), you will still need to do that manually. If you only need to install these packages on your own system then a simple "makepkg -irs" will work. If you need to share the packages then you have to "makepkg" and then <create a repo and host it|write scripts|use pkgd|do it manually|etc>.
The former is as simple as it gets. The latter will require tools or time. I opt for using tools in that case. In either case, the remaining issue is notification of the update cycle. To achieve that, you either have to check for newer versions manually or use a script. Your original post involved essentially hijacking pacman's update function using repo trickery in order to manually abort a download which you would later have to resume just to find out about new releases. That involves repo maintenance (creation, updating, cleaning) and at least 2 calls to pacman. A script to print out a list of available updates seems very much like an improvement to me. You've already stated that you don't see that as an improvement.
I suspect that I still don't fully understand what you actually want to achieve.
Last edited by Xyne (2009-09-21 02:29:37)