On Thu, 2 Jun 2011 09:57:54 -0400 erik quanstrom <quans...@labs.coraid.com> wrote:
> On Thu Jun 2 09:28:49 EDT 2011, quans...@quanstro.net wrote: > > > hi erik, i tried to install nupas with contrib today and it failed. > > > my root is from a fairly recent labs iso and, well, you can see the > > > source of the problem in the file dates: > > > > > > kolari% ls -lp /386/bin/upas/fs > > > --rwxrwxr-x M 8 glenda adm 345302 Apr 7 20:32 fs > > > kolari% ls -lp /n/sources/contrib/quanstro/root/386/bin/upas/fs > > > --rwxrwxr-x M 63 quanstro sys 400215 Jan 5 13:55 fs > > > > > > most of the nupas files; source, binary and other, failed to install > > > with the message "locally created; will not update". i guess you need > > > to touch nupas files and rebuild the package. > > > > i'd suggest moving /386/bin/upas and /sys/src/cmd/upas out of the way and > > trying > > again. there will still be some conflicts in /mail/lib, but those should > > be managable. > > to clarify, sources can be rebuilt at any time so touching > files and pushing the contrib package will only serve to > obfuscate when the files were actually last changed. it won't > prevent the nupas contrib package from "breaking" again. True that. I thought of suggesting a cron job to poll sources & rebuild when necessary, but it still obfuscates what changed and that doesn't feel right. > sorry for the inconvienence. i don't know of a better way. > it would be nice if applylog had an option to always resolve > conflicts in favor of the server. It would indeed. I looked at the -s option as per fgb's mail, but -s requires a filename implying each and every file needs to be specified I thought "blow this for a game of soldiers." Anyway, a little naivety has caused me more problems but I won't go into details. If I just grab the nupas source and mk install, will the end result be sane?
