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

Re: Plans for post-sarge: 1. Packaging internals



Hi,

First, sorry for the delay. Be sure however that, had I had a strong
opposition to the changes you proposed, I would have told your before to
avoid letting you waste your time.

Frank Küster <frank@debian.org> wrote:

> 1. introduce eperl
>
>    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"
>

OK, looks useful. Other possibilities include the use of m4 but
presumably, Perl is easier (if you know it) and more powerful. Moreover,
perl is essential while m4 is not. All I wish (FWIW) is that you don't
get to write unreadable Perl code throughout the teTeX packages, but the
example you cited is of course perfectly OK, since it is only a variable
expansion.

> 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).

I suppose that the merge (tetex-common "copied" into tetex-base or
tetex-bin) happens in the clean rule of debian/rules, so that the
.diff.gz of the to-be-generated source package contains the updated
files, ensuring the package's reproducibility.

> 3. Support for sarge users
>
>    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.

Sounds nice!

> 4. Moving configuration stuff to tetex-base

I cannot really comment on this because I don't know the precise
handling of every config file in teTeX as you do. I understand why you
want to move the files and I think you know better whether each file can
be moved safely, and easily.

> I'm awaiting your protest,

No protest from me. :-P

Regards,

-- 
Florent



Reply to: