"Luke T. Shumaker" <[email protected]> writes: > At Fri, 30 Nov 2012 15:29:56 -0300, > Nicolás Reynolds wrote: >> "Luke T. Shumaker" <[email protected]> writes: >> > It copies the packages in ${chrootdir}/srcdest to your configured >> > SRCDEST outside of the chroot; where normal `makepkg` would put them. >> >> but srcdest is for downloading sources... why copying if you can have >> them all in the same place anyway? :D > > Because the file ownership of the outside srcdest (you) and the inside > srcdest ("nobody") are different.
changing ownership is cheaper than copying files i think and you don't have to trap it to keep them in sync >> > > it may also bind mount a subdir on home where you store abslibre and >> > > libretools (i use the git version) and that's clean enough. it's never >> > > been a problem though. >> > >> > Eh, I'm a fan of getting an up-to-date libretools on the repos. >> >> it's not enough if i'm testing changes to libretools itself ;) > > Well then, that's what /repo is for, put the testing package there. i'll have to get familiar with your changes first D: >> > > > * A chroot also protects you from a misbehaving build script messing >> > > > with your $HOME. >> > > >> > > i usually check pkgbuilds from aur and trust the ones that come from >> > > abslibre... >> > >> > Not just the PKGBUILDS, but the Makefiles, ant scripts, etc that are >> > part of the source. >> >> ok then refer to mount chroot's ~ to something that contains libretools >> and abslibre (or just abslibre): >> >> $ ls ~/packages/ >> abslibre/ >> packages/ >> sources/ >> >> $ mount --bind ~/packages $chrootdir/home/$USER/ > > I'll consider this. Perhaps I'll make bind mounts configurable, so you > can configure whatever mounts you want. \o/ >> >> chcleanup is run automatically here, not optionally. -c is needed when >> >> the chroot is considered dirty if not pristine so it may remove the >> >> packages you already installed if this is the second run, and this isn't >> >> the case: chroot is considered dirty when more than the needed packages >> >> are installed. >> > >> > How is it done automatically? >> >> it's always run by treepkg before makepkg, no flag involved, and it's a >> tiny script that just knows what to remove instead of removing >> everything just in case (rsync is slow and btrfs is overkill in >> comparison to a *tiny* script that runs pacman -Rn >> packages-not-in-base-or-pkgbuild). > > How the tools clean has changed. > > librechroot -c cleans the chroot using chcleanup > librechroot -s syncs it to a pristine chroot with rsync/btrfs > > I've also just (since I started writing the email) tought libremakepkg > to also run chcleanup for every build, since it isn't overkill like > the old package cleanup was. that's what i meant :D >> >> recreating here means "mounting and umounting, removing files, spawning >> >> shells...", why has this to be done many times when i can do it once or >> >> less? (yeeloongs aren't the quickest machines). >> > >> > I wish I hade a yeeloong to verify... >> >> :c >> >> but still, doing things many times unnecesarily doesn't sound kiss to >> me, as in i didn't had to rewrite libremakepkg, i just stopped using it >> ;) > > My goal with rewriting libremakepkg was to "wrap makepkg, adding hooks > to do things for me that I'm doing manually now". ok >> > It's pretty minimal now. The most complicated parts are: >> > * handling signals to umount and exit gracefully >> >> that's the problem with making it mount everytime instead of using >> fstab, you can end up with the same dir bind mounted many many times. > > I think I fixed that bug. Before it trapped the signals so that when > there was an error, it went to the umount function. The first thing > that function did was reset the traps to the exit function. This was > bad because it meant that it might exit early and not umount > everything. > > I think that modifying the outside fstab is too invasive into the > user's system. we could also check if it's already mounted, just in case >> > * the legacy code that only runs if systemd-nspawn isn't available >> >> this should be deprecated imo > > I agree, but removing it would involve patching devtools even more > than I already do. I'm trying to keep it so that I can still pull > changes from devtools. ok... have you asked about the gplv2? >> > And some of the "checks" can only be done with a chroot, such as >> > turning networking off during the build and package stages. >> >> this is true, but what we're discussing (except from the "running any >> command instead of a predefined set" part) does still apply. > > I'm not sure what you mean. In order to toggle the networking you must > exit and re-enter the chroot. > i mean the changes we're discussing aren't specific to the way the chroot is handled and benefit both :O feature request: is it possible to run dbus+avahi-daemon on the chroot, or make it available from the host system? now that avahi is a dependency of distcc i wanted to try +zeroconf (my build machines are changing ips a lot lately...) but it couldn't connect to the host avahi. pd: i just learned how to pull submodules! -- http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
pgpH9guMfPb4i.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.parabolagnulinux.org/mailman/listinfo/dev
