Plans for post-sarge: 1. Packaging internals

[Frank Küster <frank@debian.org>]

Hi all,

I've been working again on the packages for the current beta, and I
would like to suggest some changes in the way we do our packaging.

1. introduce eperl

   Many times I struggled with the fact that the same files are acted on
   in several scripts, like rules, preinst, and postrm, or whatever. And
   when I make changes, I quite often forget to check which files need
   the change. Up to now and IIRC, this has only happened during package
   testing, not in uploaded versions, but it's only a question of time...

   One approach to make maintenance easier in this respect would be to
   generate the files using eperl. I have encountered this system first
   when looking at the auctex package, and I must admit the first
   encounter wasn't too friendly. But after one has become acquainted to
   it, I think it's really great.

   Instead of editing, e.g., postinst, you edit postinst.in, and mixed
   with the code as we know it it contains eperl statements - mostly
   just variable substitutions like

   TEXMFD_UCF="<:=$TEXMF_PARTS:>"

   According to the rule

   % :: %.in common.variables_update $(eperlfiles) 
        eperl -P -o $@ $<

   the eperl statement between <:...:> will be replaced. All files will
   include debian/variables, were we write

   <:$TEXMF_PARTS="05TeXMF 15Plain 45TeXinputs 55Fonts 65BibTeX 75DviPS 85Misc 95NonPath":>

   And can reuse the list everywhere. So this gives, in the final
   generated postinst:

   TEXMFD_UCF="05TeXMF 15Plain 45TeXinputs 55Fonts 65BibTeX 75DviPS 85Misc 95NonPath"

   My current version of tetex-bin_2.96.7.20040721 is yet eperl'ed
   (except debian/rules), and I think it rocks...

2. Once we've done that, I'd suggest to create an additional CVS tree
   besides tetex-bin and tetex-base, called tetex-common or the like. It
   would be checked out in a directory somewhere above the package build
   directory, and in Debian rules one target would check if it exists
   and update a common.variables file (and possible more files, see
   below) to the build tree. This way, things can be easily kept in sync
   between the two closely related source packages.

   Developers would usually have that tree, while ordinary users can
   still build the package without it (I have yet implemented this).

3. Support for sarge users

   I still think that our decision not to package the teTeX beta was
   right. However, sarge users will not be happy to use tetex-2.0.2 for
   the next two years or so.

   I think we should not just leave the problem to the users or
   individual backporters. Rather we should try to keep our packages
   compatible with sarge. I suggest that we keep a "debian/sarge/"
   subdirectory with appropriate patches for the packaging scripts, and
   a sarge target in debian/rules that applies those patches (and a sid
   target that reverts them), including a new debian/changelog and an
   according version number.

4. Moving configuration stuff to tetex-base

   Looking back at the last year or so that I closely followed the
   debian-tetex-maint list, I find that the vast majority of uploads of
   tetex-bin were "architecture-independent" things - changes to the
   handling of configuration files (i.e.: text files) in the maintainer
   scripts, changes to configuration files, to update-texmf and so
   forth. Each time the whole tetex-bin package had to be recompiled for
   all architectures - this puts additional load on the buildd's, and
   might once cause a delay of tetex moving into testing.

   This problem could be minimized if we moved as much as possible of
   all this to tetex-base (as the architecture: all source package that
   does not need the buildds). What could we move?

   - language.dat is yet in tetex-base, the maintainer script handling
     of it could be moved, too. 

   - texmf.cnf is put together from the files in texmf.d, which are
     added in diff.gz, and could easily go to tetex-base. Also moving
     update-texmf would not add any dependencies to tetex-base AFAIS.

   - fmtutil.cnf and updmap.cfg are from tetex-bin, but just adding
     those two files in diff.gz would be no big deal. We just have to
     remember to update them when they change (fmtutil.cnf is generated
     in tetex-bin from fmtutil.in), but that could be accomplished with
     the tetex-common tree. Then update-fmtutil can go with it (and
     update-updmap can be dropped, anyway).

  
I'm awaiting your protest,
Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie