Igor Pechtchanski wrote: > Technically, these packages *do* require bash, and coreutils, and possibly > others, so automatic dependency detection is hard (we don't want to have > setup parse shell scripts). Perhaps we should augment the "depends" > function of the g-b-s to also look at the postinstall script and find > packages for all commands invoked in it?
Well hopefully, most (or all) of the coreutils commands will be plain binaries in /usr/bin, and not hard links or anything that requires fiddling from a postinstall. In other words, coreutils should be functional as soon as it's unpacked, so it doesn't really matter if package foo runs its postinstall before coreutils. In fact it doesn't even look like coreutils currently has a postinstall. Even still, because of the fact that it's in many "requires" lists coreutils is going to always be near the top of the "dependency sorted order list" anyway. I have a feeling that bash and coreutils will tend to "bubble up" to the top of it regardless, even if there are some cases where the explicit dependency in some packages is not spelled out. > * io_stream.cc (io_stream::open): Better log message on error. > (io_stream::mkpath_p,io_stream::remove,io_stream::mklink): Ditto. > (io_stream::move,io_stream::exists): Ditto. Looks fine, go ahead. Better error messages are alwasy good. :-) Though I wonder if all those repeated throws should be a macro or inline instead... Brian