[tex-live] Package preparation question (directory structure)

Urs Liska ul at openlilylib.org
Sat Sep 7 23:55:11 CEST 2013

Hi Karl,

now I'm going through your email point by point.
The good thing to start with: Most of it is clear, I have implemented 
many things.
Others simply have to be done in the 'deploy.py' script. But I didn't 
want to hold back this email until this is finished (because this more 
or less will be the last thing to do), so when you read "OK, TODO" you 
can consider it understood and don't have to comment on it anymore.

Am 05.09.2013 00:45, schrieb Karl Berry:
>      Do I have to also supply the Metafont sources for these fonts or is
>      it sufficient to supply a link to the original developer's Git
>      repository in the FONTLOG?
> I'm not sure I'd go so far as to say "have to", but unless perhaps they
> are terrifically huge, in principle I would have to recommend it.  The
> exact sources that create the OTF's you are distributing.  The idea
> being that someone who wanted to work on the package would have all of
> the ultimate sources that went into it.

Done. Although I'd prefer any modifications be done on the original, 
LilyPond sources.
This added not more than a ~150KB zip to the package. And it is from a 
checkout of exactly the LilyPond version the binary .oft files are, 
which is definitely better than simply pointing at the repository and 

>      Is it better to have the sources and the .pdfs of the documentation
>      (manual and examples) together in /doc/lilyglyphs or do the sources
>      go to /source/lilyglyphs/doc?
> They don't have to be together, but, like Robin, I recommend it.  Thus I
> suggest putting them into the same doc/ subdirectory.  In the uploaded
> zip:
> lilyglyphs/README            (Must be named "README", specifically.)
> lilyglyphs/doc/*.{pdf,tex}.  (No "/source/" level.)
>      [many small pdfs]
>      /tex/latex/lilyglyphs/glyphimages/pdfs
> 1) Basically, yes.  For CTAN, your zip should have this:
> lilyglyphs/tex/pdfs/*.pdf.  For such a large number of files, it only
> makes sense to have them in a separate subdir.
> (CTAN folks will effectively unpack your uploaded zip to end up in
> m/l/c/lilyglyphs/..., and I will import it into TL under (these days)
> texmf-dist/{tex/latex,...}/lilyglphs.  But this is not your
> responsibility. :)


> 2) Please ensure the base filenames are unique.  Being in a unique
> directory doesn't help with that, unfortunately.  I fear this is going
> to be the biggest problem you have.  Inserting lots of files with
> generic names like "crotchet.pdf" and "quaver.pdf" sounds bad to me --
> other music packages or user documents might well be using them.  I
> suggest prefixing them all with lgl- or something.  Ugly and painful,
> but have to do something.

Done, at this early time it was simply a matter of renaming 2*28 files 
with a simple shell command and updating 28 LaTeX commands for which it 
was easier repeatedly hitting Ctrl-V than hacking a script.
The generating scripts have been updated accordingly, so any new files 
will have a 'lily-' prefix which is less ugly than lgl- and should 
definitely be sufficient with regard to unique file-names.

>      but I don't know what to do with the rest.
>      /glyphimages/definitions
>      /glyphimages/generated_src
> Since those are source files not read by TeX, I would put them into a
> source/ subdirectory.  Specifically, for the zip:
> lilyglyphs/source/definitions
> lilyglyphs/source/generated_src
> I'm not sure the /glyphimages/ level buys us much here, but doesn't seem
> like a big deal either day.


>      The package contains a set of Python scripts
> I recommend this, for scripts that the user invokes from the command
> line (which I think is what you're talking about):


> lilyglyphs/scripts/*.py


> I think scripts not intended for the user to run (deploy.py?) would be
> better in:
> lilyglyphs/source/scripts/

You're right, but his won't be copied to the package at all, it's just 
for 'internal' use.

> The script names also need to be unique (since they'll end up in
> /usr/bin, eventually).  Again I suggest an ugly prefix like lgl-.
> "gen{Image,Glyph}Command" could be anything from anywhere, sorry to say.

Ah, this is something I hadn't thought of.

> Uh oh, I also see lilyglyphs_common.py.  I suspect that is library code
> used by the others?  That complicates things even more.  I'll save that
> for the next round.

Exactly, this is 'import'ed by the other scripts.
I do not see why this complicates things, but I'm looking forward for an 

>      how should I direct the user (in the manual)
>      so he can make use of these scripts?
> The manual could say that distros (either OS-level [Debian, etc.] or
> TeX-level [TL, MiKTeX]) will make the scripts available in the regular
> binary directories.

Good idea.

> As for users who install by hand, instead of writing out laborious and
> lengthy and error-prone instructions, I suggest advising them to look at
> the installation in TL.  (Or simply download our .tar.xz files for
> manual installation ... anyway ... another time ...)

OK, I'll see how to do this.

>      * The package provides a 'shadow' structure of the above /glyphimages
> Where is this in your git tree?  Anyway, do you mean something like a
> skeleton directory tree?  I suggest making a .zip out of it and
> including that file in your tree.  If users can't run unzip
> successfully, it's hopeless anyway.
> lilyglyphs/doc/usertree-sample.zip

In the git tree it's lilyglyphs_private. And yes, it's a skeleton 
directory tree very similar to the glyphimages directory.
I already intended to make a zip (but only in the final deploying stage).
What I didn't know was to put it in the doc directory.

> Hope this helps.  Let us know what remains unclear; I'm sure there is
> plenty :).

Sorry to (maybe) disappoint you, but I don't think you have left much to 
be asked ;-)
If I see correctly only one of the questions hasn't been finished, the 
Python library file.
I hope that - once I'll find some time - I'll now be able to prepare a 
usable zip file ...


More information about the tex-live mailing list