On Thu, May 22, 2008 at 4:13 PM, Michael Klier <chi@xxxxxxxxxxx> 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
