On Thu, May 22, 2008 at 4:13 PM, Michael Klier <chi@chimeric.de> wrote:
Hi Archers,
in the past weeks there was a little discussion in the forums about the purpose of ABS vs. AUR and when to use which of both tools. Srcpac was mentioned as being the right tool to install customized packages from the already existing PKGBUILDs in the ABS tree. However, srcpac didn't work since abs.conf moved and other minor things that changed (makepkg doesn't like to be used by root etc.).
I took to opportunity to fetch the srcpac git repo and get it working again, because I think it makes a good addition to ABS + pacman.
Instead of sending a bunch of patches I've setup a public git repo where you can fetch it and give it a testrun if you like (I can send patches too if required):
http://dev.chimeric.de/git/srcpac.git
I've also changed a couple of things. These are merely suggestions, which are of course disputable ;).
I completely dropped the srcpac.conf in favour of another approach. srcpac now looks for config files in /etc/srcpac.d/<pkgname>. You have one config file per package. These files contain only sed expressions (they're just simple sed script files) and have to be named exactly like the corresponding folder (package) in the ABS tree ie. "python-doc", or "most". IMHO this is much more clear (KISS if you like) than having one config file containing stuff like "pythonXdoc=('#sedexpr#' '#sedexpr#')" which gets really messy when you change lots of things.
Another possibility would be to keep the modified PKGBUILDs in /var/srcpac/<repo>/<pkgname>/PKBUILD and completely drop sed, though I think the sed approach requires less work.
Because makepkg doesn't like to be run as root there were also some implications for building packages. To resolve them I decided to use a new user named srcpac and a dedicated build directory /var/srcpac in which the packages are build instead of building directly in the ABS tree. srcpac will drop privileges for the build process to this user.
I also had to introduce a little perl dependency :( (just a oneliner) to be able to sanitize packages names from urls. The bash expression which was originally used didn't work anymore and the suggested fix in FS#8434 worked only partly and not for all packages. However, I failed to get the thing right in sed, thus the perl oneliner. If someone has an idea I'd greatly appreciate it (see get_pkgname()) (examples of packages which fail with the fix suggested in the bug report, because they're versioning scheme is a little different, are feh and most).
Instead of using makepkg -i to install the newly build packages on the fly, srcpac uses pacman -U now, this way it's now possible to specify a different target root directory when build packages from source (this was marked as missing feature).
From the test I've run up to now everything _seems_ to work as expected, but it would'nt harm if someone else who's interested in this could give it a try :).
If you plan to try it you have to do the following things before running it (I can provide a PKGBUILD if needed): - add a new user 'srcpac' - create /var/srcpac and grand permissions for srcpac
That's it, what do you think about it? I am open for suggestions in any direction (+thx for reading this rather lenghty mail ;)).
Best Regards + TIA for any feedback, Michael
PS.: The original srcpac.conf is still in the repo, and I haven't touched the manpage in advance.
-- Michael Klier
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFINf4zAuL1i4MI9VERAsscAJ41O7WNrQIKsoDBVOKh5j7B9P4++ACeMNSK XAXVVQ6YiStrCUMBTOBn1A4= =m8CM -----END PGP SIGNATURE-----
Hot! I was hoping someone would do this. I originally wrote srcpac as an example of how such a thing could be done. Then people actually started using it! I will do my best to look at your patches tonight. I'll even put a reminder in my phone. I'll get back to you tomorrow about it. Jason