This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [ITP] quilt-0.43 -- Tool to work with series of patches
Brian Dessent <brian-Uo+tbPwr0tHR7s880joybQ@public.gmane.org> writes:
> Jari Aalto wrote:
>
> The following files in the binary package are perl scripts (with
> #!/bin/perl as the first line) yet you don't list perl in the
> "requires" line. Is this package meant to be usable without perl
> installed or is this an oversight?
Thanks. fixed.
> /usr/bin/guards
> /usr/share/quilt/scripts/dependency-graph
> /usr/share/quilt/scripts/edmail
> /usr/share/quilt/scripts/parse-patch
> /usr/share/quilt/scripts/remove-trailing-ws
>
> The postinstall/preremove system seems unnecessarily complex. It includes
> nearly 250 lines of shell script and two manifests to do what could be
> accomplished simply with:
The build system is generic and meant to adapt for any package. It is not
written for quilt specifically.
> ...and by locating the default quiltrc file under /etc/defaults
> instead of stashed away in
> /usr/share/doc/quilt-<VER>/examples/quilt.quiltrc and requiring all
> that scripting to locate.
I need more information. The original quilt installs file to:
/etc/quilt.quiltrc [1]
which would conflict with user settings during upgrades. So the file
is relocated with (CYGBUILD/install-after.sh) to:
./usr/share/doc/quilt-0.43/examples/quilt.quiltrc
That file will be installed to [1] by postinstall, if user did not
have [1] already.
I was under impression /etc is under user's control and scripts should
not overwrite files there. Is the /etc/defaults/* is meant to be used
differently? Like that you suggest using it for example files?
> And these scripts have code for printing
> warnings/messages to stderr but all postinstall/preremove scripts
> run in setup.exe with both stdout and stderr connected to /dev/null
> so this can serve no purpose.
The messages for the porter to verify the steps. They are no-ops
during setup.exe
> However, it seems like these scripts are probably provided from some
> generic build system (cygbuild?) and so if it's easier to do it the
> overly-complex way then go with that. Still, it seems a lot more
> error-prone.
True, but when prepremove/postinstall runs, the system is "clean" It
would help if cygbuild were available so that the additional scripts
could use it as a "library" and not duplicate the functions.
Now the install scrips are self sufficient itself.
> Source builds fine, everything else looks OK.
Good, thank you for testing.
Jari