Re: [Quilt-dev] distributing the files (was: [Quilt-cvs] quilt configure.ac quilt.changes)

[Martin Quinson]

Hello,

On Thu, Nov 20, 2003 at 12:10:13PM +0100, Andreas Gruenbacher wrote:
> Hi Martin,
> 
> On Thu, 2003-11-20 at 12:11, Martin Quinson wrote:
> > In the same time, I'll update the list of scripts in po/Makefile and
> > translate the missing strings to french. The best would be to use the same
> > list for both ./Makefile and po/Makefile, but it would need to split the
> > variable definition out of the ./Makefile to include those definitions in
> > po/Makefile. That's a bigger change I do not trust myself to do since I'm
> > not very familiar with your makefile...
> 
> Is there a problem with using the full list of commands and scripts?
> `bash --dump-po-strings' seems to do the right thing ...

Yes, but you have to list the scripts in the QUILT_IN variable, which is
also defined in root Makefile, thus my idea of the creation of a Makevars,
and its inclusion in both the root Makefile and the po/Makefile. That ways,
the po files will never lag behind in case of inclusion of new commands again.

> > I also have a bug openned against the debian package asking for a man page,
> > and saying that the content of README changed to groff would be cool. But
> > since this document is generated, I'm not sure of what the best solution is.
> > I may do a perl script engroffing the README to make sure that the man page
> > will keep uptodate, but it does not look trivial to do. Any better hint?
> 
> I think the best solution would be to write a short man page that gives
> a very brief overview of what quilt is and how it works, and refers to
> the paper, `quilt -h', and `quilt cmd -h'. Feel free to use text from
> doc/main.tex for that. Parts of `Basic Concepts and Operation' appear
> useful for that. The README file no longer explains any concepts
> (because that is now covered by the paper), and could as well go away
> IMHO.

Yes, I guess I'll go that way.

> I have once asked to move the script currently found in /usr/share/quilt
> to /usr/lib/quilt, because they are really system dependent beacuse of
> utility path names substituted in the scripts. How about that? I would
> like to make that change soon.

I'm sorry if I didn't answer. That's because I'm not sure about that. I
would say that /usr/lib are for arch dependent files, and not for system
dependent ones. But I would have to check the FHS again to be sure.

IIRC, compiled stuff goes to lib, but having hardcoded paths is not a
sufficient reason to go there (in the spirit of the FHS). I'll try to check
this again...

Bye, Mt.

signature.asc
Description: Digital signature