Maybe pbuilder could incorporate the name of the distribution (and possibly the architecture) into the base.tgz filename and then use that automatically. Since sid is the default if no distribution is given, the default base.tgz should be named base-sid.tgz, which could be a symlink to base.tgz. I always have to specify pbuilder ... --distribution sid --basetgz .../base-sid.tgz Of course I have that scripted (in .pbuilderrc), but it would be best if pbuilder could just support this. It could always fall back to just base.tgz if base-$(DIST).tgz does not exist. And for execute or login, I would now specify --distribution as well, which would select the right base.tgz file. The --basetgz option is still useful to override that default. Cheers,
regards, junichi
also sprach Junichi Uekawa <dancer@netfort.gr.jp> [2006.06.16.0145 +0200]: This is not my point. I would love to see pbuilder support different basetgz with codenames instead of full pathnames. But maybe this is just my wish.
From the designing and extention perspective, I do not like embedding names; I'd like the name to be left to the system administrator. /usr/share/doc/pbuilder/examples/pbuilder-distribution.sh is one example script which would probably be more convenient than having such an option. regards, junichi
Hi Martin,
I had the same problem than you, and ended up using this shell snippet
in my pbuilderrc:
# archived chroot image location
if [ "$PDEBUILD_PBUILDER" = "pbuilder" ]; then
BASETGZDIR="$PBUILDERROOT/basetgz/$DISTRIBUTION"
create_dir "$BASETGZDIR"
BASETGZ="$BASETGZDIR/base.tgz"
fi
/usr/share/doc/pbuilder/examples/pbuilder-distribution.sh is another
solution.
Do you agree this feature can be handled by end-user configuration?
Should be keep the bug open?
Bye,
also sprach Loïc Minier <lool@dooz.org> [2006.10.22.1606 +0200]: Certainly. I've been using http://svn.madduck.net/pub/bin/pbuilder/plogin, which can be symlinked to pexecute, pbuild, pupdate, and pclean. Those five take care of my pbuilder needs. To build packages, I use pbuild, or, if that's not available, the same sort of idea in dbuild: http://svn.madduck.net/pub/bin/debian/dbuild. (updates to these pending, I am on the train now and rewrote parts) Well, it kinda depends. I think it's always nice to get rid of wrapper shell scripts as functionality moves to the core -- pbuilder in this case. If it won't get fixed, tag it wontfix. Okay?
Your wrappers are full or personal customizations. I think a lot of people are customizing their systems like this. Concerning this particular config, basetgz (but basepath suffers from the same problems), I'm not sure it would be wise to specialize the default name. The reasons against the change I see are: - this would make it rather hard to handle dist-upgrades of the contents of the pbuilder (how do we detect a change from sarge to etch? should we rename the tarball after the upgrade?) or mixtures of various distribution (how do you name a pbuilder which is setup for sid + $company repository?) - this naming scheme is arbitrary, we could base the name on the login of the unix user doing "sudo pbuilder create" - this is easily configurable, we already found three completely different implementations of this config The reason I see in favor of the change I see is: - would make it easier to have out of the box support for creation and usage of one pbuilder per dist The most flexible approach remains (IMO) the current one where this is simply configurable. Out of curiosity: what's this "phoenix" shell you're using?
also sprach Loïc Minier <lool@dooz.org> [2006.10.28.1546 +0200]: Exactly why I think we should move the feature upstream. this is up to you. yup. pbuilder has so many complexities that I just would not call it simply configurable; you can do so much wrong. Even just command line handling is a major PITA at times. http://svn.madduck.net/pub/bin/base/phoenix I exited the chroot too many times by accident. :)
Hmm, I didn't express it, but I also wanted to write that people are doing /different/ customizations on each site, on each machine; /weird/ things, like we both do. But certainly this is one of the most common customizations. I call it too hard and risky for now and for me, so I wont touch it myself right now. O:-) It's already complex, and yet this bug is about a new feature to remove some complexity, but also to add some! :-) Thanks for discussion,
Hi, FYI See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398404 (I am polishing detail of script here) This is another attempt to do one base.tzg per distribution. Regards, Osamu