2006/12/20, Aaron Griffin <aaronmgriffin@gmail.com>:
3. I posted a patch for #5223 (source cache) and it has been patched. However, it is now a triple conditional with three different possible locations for package source (current dir, $SRCDEST, and /var/cache/pacman/src). Is the last one necessary since it is highly recommended to not build as root? Should we deprecate this path? Looking even further ahead, should we make fakeroot a requirement for running makepkg?
Hmmm. Building as root _is_ actually used in one or two oddball cases (Judd knows what they are) so explicitly denying them may not work. As for the SRCDEST check... why not default SRCDEST to the pacman cache dir, and just check one single place for it. It makes sense to me.
Currently makepkg downloads files with wget into the same dir where PKGBUILD is. So if we gonna use SRCDEST only, it should write it there. But /var/cache/pacman/src is owned by root. :( It's weird, but even when I make .../src dir owned by my user - makepkg doesn't put file there after download. What fakeroot gives instead of chroot?
6. Overabundance of options in makepkg- I was trying to find a new letter for a '--repackage' option and we are pretty much out of lowercase letters. At the moment we have two basic types of options: things that can be done in the pkgbuild options line, and things that directly affect the way makepkg works (geninteg, skip integs, location of PKGBUILD). Are the first type truly necessary? It would make makepkg a bit more streamlined if the only options were those that can't be done somewhere else. So i propose the '--nostrip', '--keepdocs', and any other option like this be removed.
No! Because then user cannot get exactly the same results on his box without knowledge of those --nostrip/--keepdocs etc. options given by package maintainer. Then he will build some package without --nostrip and will wonder why it doesn't work.
I couldn't agree more. Perhaps it's time to split makepkg into two different scripts. I don't know if I can see a good dividing line, however. Alternatively, we don't really need command line options for _every_ config setting. Perhaps we can limit these in some way... I'll look into it tonight as well.
Two scripts? 1) why? 2) what they should do?
Ideas for backends are always welcome. The interface exists in be_files.c in libalpm. It's fairly straightforward. People seem to prefer a "real database" backend (while at the same time suggesting sqlite which is far from a real database, but I digress), but I think that is overkill. There are a few ideas I had milling around, but haven't fleshed anything out - discussion is always a good idea.
There was a patch against 2.9.8 that added gdbm support. I dunno if it was adapted to pacman 3 later. I can resend it to you, or maybe I'll find the bug #. -- Roman Kyrylych (Роман Кирилич)