This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Multiple pending setup patches


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]