[pacman-dev] My thoughts for development
roman.kyrylych at gmail.com
Wed Dec 20 15:32:59 EST 2006
2006/12/20, Aaron Griffin <aaronmgriffin at 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
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 (Роман Кирилич)
More information about the pacman-dev