On Sat, May 28, 2011 at 05:36:12PM +0900, Norbert Preining wrote: > On Sa, 28 Mai 2011, Jan Hauke Rahm wrote: > > Good morning, Norbert, > > Good evening. ;) > > > 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? > > Yes, exactely. That is the primary distribution media of TL, please > see CTAN/systems/texlive/tlnet/ Okay, looks reasonable. Would you mind writing a fine-line recap about what texlive.tlpdb is used for? I see a few perl modules but didn't look much into it right now. Is that the unpacking logic or something? > > > 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 > > Not really, because we don't have nice version numbers. > > Well, in principle we could: > - rename the .tar.xz (is .xz allowed in dh7?) to > (e.g.) 12many_2011.2011.05.29.orig.tar.xz > where the first 2011 is the general revision number, and the second > is the date from which we took the tlnet mirror (which is updated > daily). That looks good, yes. (xz is possible with dpkg source format 3.0; unfortunately, ftp-masters only allow gzip and bzip2 these days if I remember correctly.) > > > texmf-dist (TeX Live proper) ---> /u/s/texmf-texlive (Debian) > > > texmf (TeX Live proper) ---> /u/s/texmf (Debian) > > > > Is upstream using such logic or why do have to put up with such in the > > Yes, upstream has texmf and texmf-dist, that are related to the kpathsea > vars > TEXMF > TEXMFDIST Care to explain why? I mean, shouldn't we install in TEXMFDIST and leave the other empty or is that something the tl package manager needs? (Read below) > > > - unxz/tar the additional-files-$binpackage.tar if present into > > > debian/$package/ > > > > What additional files are we talking about? > > We might ship something else ... and might have to move some > files around a bit ... you never know. Okay, well... Using format 3.0 would unpack additional tarballs into equally-named subdirs, e.g. orig.tar.gz --> $pwd/ debian.tar.gz --> $pwd/debian myapp.tar.gz --> $pwd/myapp That means, if we simply need to install all files of myapp into a package myapp, it's as simple as having 'debian/myapp.install' contain myapp/* dh_install will do the rest. The only thing we need to look out for if we use additional tarballs like that, is not to have the subdir in $pwd already, i.e. if orig.tar.gz already unpacked a myapp directory, that would be overwritten by what myapp.tar.gz gets us. > > > - 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... > > No, the licensing issue is irrelevant here, that is fullfilled because > we recommend the doc packages (we have decided so). > > It is only about practical purposes. Okay, so the doc packages are entirely different source packages? > > > - move info files to appropriate places > > good thing is that we don't have to care for anything else anymore. ...because we install into TEXMF and TEXMFDIST just like upstream wants to, right? Well, I'm not objecting to this -- quite the opposite, let's stick with what upstream brings -- I simply don't get why they split in the first place... > > > - 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? > > There might be single files which we have to blacklist, but not the > whole package. We have two levels of blacklist. Ah, alright. We maintain a package blacklist that is considered at source package creation and another file blacklist that is used to falsely installed files in the binary packages, right? If understand that correctly, the second list can basically be read by find -delete after dh_install, right? > > Whatever simplifies the process if perfect, really. About a year ago, I > > I am playing with the idea to throw away *EVERYTHING* what has > accumulated in the tpm2*.cfg and src file and start afresh ... > just to make a clean start. Maybe most of the things are not > really necessary. And if we can easily make a new upstream release > based on a new tlnet snapshot it might be easier to fix it upstream > and then package it here. Absolutely! > Only problem, I guess I have to implement it ... Well, if you want to, let's use a wiki page on wiki.d.o and first describe what we get upstream and what technique they use to install the files. Then we can describe how we want it to be split up into binaries. That might help getting a clear overview and it might help me (and possibly others) to suggest implementation details. You wouldn't have to do it all by yourself, but it's your call. Since we would start from scratch anyways... with a project of this size, I'd find git better than svn. It allows more pactical branching and stuff but, most importantly, it is decentralized. Some changes need multiple commits to be readable and functional. Using git, one could experiment more easily at home, commit whatever one wants, and later on, if it's really working, push it to git.d.o. I know this would break quite some workflow. But a rewrite is the best moment to consider this. Moving history from svn to git is exremely complex for projects that big. (Also, git-buildpackage works better with source format 3.0 and different compressions. Since I'm co-maintainer on svn-buildpackage, I know that it's not going to be implemented there soon.) 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