[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TL 2011 packaging



Good morning, Norbert,

On Sat, May 28, 2011 at 03:47:37PM +0900, Norbert Preining wrote:
> since I want to see TL2011 soon in Debian, here are some ideas
> on how to rework the packaging completely, and allowing easier
> update to newer versions/intermediate releases.

Nice, thanks for working on it!

> Please commnet, esp on the proposed reshuffling of files in
> texmf and texmf-texlive.
> 
> New way of building Debian packages for TeX Live:
> =================================================
> 
> New starting point is a tlnet archive, ie the .tar.xz.
> 
> source package layout:
> ----------------------
> texlive-base-2011.orig.tar.gz contains
> 	texlive-base-2011/archive/*.tar.xz
> 	texlive-base-2011/tlpkg/texlive.tlpdb
> 	texlive-base-2011/tlpkg/TeXLive/*
> for each included package. So a slice of the tlnet dir with all
> packages not included removed.

Not sure I get it... Is that, for each package included in texlive there
is a .tar.xz while texlive.tlpdb and tlpkg/TeXLive/* hold structural
data for texlive itself?

> texlive-base-2011.debian.tar.gz contains
>   	texlive-base-2011/additional-files-$binpackage.tar
> for files we have to move/add or do anything else
> 	texlive-base-2011/debian/*

I was thinking (but maybe I misunderstood you) that using source format
3.0 would help us out already. Additionally to the orig.tar.gz there can
be unlimited amounts of *.tar.gz (or bzip2 of course), one of which is
mandatory: debian.tar.gz. That means, we could use upstream's original
tarball, maintain debian specific parts as usual and generate additional
tarballs on the fly. They get unpacked into equally-named directories.
Wouldn't that spare us some logic when creating the source package? Or
is that what you had in mind anyways?

> Building source package will only need the following information:
> - blacklisted packages
> - additional depends/recommends/...
> - docsplitting
> - other debian related things like maintainer, version, ...
> these will be collected in tpm2deb-source.pl
> 
> 
> binary package building:
> ------------------------
> - unxz/tar all the archive/*.tar.xz, taking care for the RELOC packages,
>   into debian/$package/usr/share/texmf-texlive/
>   and debian/$package/usr/share/texmf/
>   ATTENTION!!! This will be a change because we will identify
>   	texmf-dist (TeX Live proper)  ---> /u/s/texmf-texlive (Debian)
> 	texmf      (TeX Live proper)  ---> /u/s/texmf (Debian)
>   Currently we are mapping everything into texmf-texlive and only
>   a few files into /u/s/texmf. But since I don't expect any other
>   TeX distribution to come up for now I would like to keep it easy
>   and simple, with the same layout.

Is upstream using such logic or why do have to put up with such in the
first place? I don't really see what splitting up anything would gain
here...

> - unxz/tar the additional-files-$binpackage.tar if present into
>   debian/$package/

What additional files are we talking about?

> - apply the file move and remove etc directives from the tpm2deb-bin.cfg
>   (former tpm2deb.cfg) file by physically moving the files around.
> 
> - move the doc files (do not use the above for that) to the appropriate
>   place (doc splitting or independent package)

I thought the doc-splitting was a license issue and had to be done while
creating the source package...

> - move info files to appropriate places
> 
> - generate license information from texlive.tlpdb, fix man pages etc etc
> 
> - run dh_ scripts
> 
> The tpm2deb-bin.cfg would contain only
> 	blacklist;file;		(or equivalent)
> 	mapping;		(or equivalent)
> what remains in the current situation is 
> - special;.*/([^/]*\.info);install-info;
> 	see above, special rules or tpm2deb-bin action

Now I'm really confused... The blacklisting, is it done when creating
the source package, i.e. the blacklisted package never get uploaded, or
are they part of the source package but don't make it into binary
packages?

> NOT NEEDED ANYMORE, done via trigger
> 
> - luatex special cases to build format dumps
>   execute;texlive-base;AddFormat name=luatex engine=luatex patterns=language.def options="luatex.ini" 
>   execute;texlive-base;AddFormat name=dviluatex engine=luatex patterns=language.def options="dviluatex.ini"
> 
> No idea if that is needed?!?!
> 
> ----
> 
> source package
> - build-orig-tar
> 	reads config files
> 	reads texlive.tlpdb
> 	generates the list to be included
> 	copies the .tar.xz (including .doc and .source) (taking blacklists etc
> 	  into account)
> - make-deb-source
> 	reads config files
> 	reads texlive.tlpdb
> 	generates the list to be included packages
> 	generates debian/control file from it
> 	generates additional-files-$binpackage.tar if necessary

Whatever simplifies the process if perfect, really. About a year ago, I
found myself trying to rewrite debian/rules(.in) to use dh7 style
techniques. I thought, some of them might even already simplify stuff.
If I can help there in any way, say so. Unfortunately, the current
process is so tweaked, it was hard to get. So, bear with my possible
beginner's questions. I hope I can be of help in the long run...

Hauke

-- 
 .''`.   Jan Hauke Rahm <jhr@debian.org>               www.jhr-online.de
: :'  :  Debian Developer                                 www.debian.org
`. `'`   Member of the Linux Foundation                    www.linux.com
  `-     Fellow of the Free Software Foundation Europe      www.fsfe.org

Attachment: signature.asc
Description: Digital signature


Reply to: