Bug#688041: Please confirm
On 11.10.2012 20:53, Frank Kuester wrote:
>> Now, if you insist on keeping the debian package == Tex Live collection
>> correspondence,
>
> We do not insist. We already have implemented docsplitting.
Judging by his actions as well as his words, Norbert does insist.
In his view, any change in packaging has to be done upstream.
>> no matter what inconveniences might occur from that
>> decision, then you can close this bug as "wontfix", since any solution
>> can only contradict with that axiom. That way at least you won't have
>> yet another bug report rotting in the BTS.
>
> Either you or someone else interested in this bug comes with a solution
> that works ...
> (
> and that includes 1. a scheme for splitting, or in other words
> combining collections to a couple of Debian packages, and 2. a proposal
> on how to implement and maintain that (when new fonts are added
> frequently!)
> )
I have already proposed a solution. But maybe it was not detailed
enough? Not that anyone would have told me...
A scheme for splitting:
By a new configuration option in all/debian/tpm2deb.cfg selected
collections could be marked for splitting into their TeX Live packages.
The collections would be split up into single TeX Live packages, with a
dependency package for the collection, that depends on all of them. Only
direct dependencies would get a separate package that way, any recursive
dependencies would be included into the package that depends on it or -
if there is more than one - into a new -common package, which every
package in the collection depends on.
How to implement and maintain:
Aside from setting the config option for the collection, everything can
be automated in the scripts tpm2deb-source.pl and
all/deb/tpm2debcommon.pm. Those scripts have access to any dependency
information needed for splitting the collection according to this scheme.
When new font packages are added to the collection, they would
automatically get their own packages when the script is run.
If it is a problem that new debian packages would be generated as
frequently as new fonts are added, the list of separate font packages
could be listed in detail in the configuration option (making it a bit
less readable, though). The implementation could then collect the new
fonts into a separate -others package that would in every aspect act
like a single font package which happens to contain a growing number of
fonts until someone adds them to the list in the configuration. That
-others package would of course have the disadvantage of unsteady content.
> ... or this problem - be it a bug or not - will never be solved. Since
> you've already talked for two weeks and not produced a single line of
> code or splitting logic,
Don't blame that on me. It is clear that I will not put my work in
writing code to implement a solution that the maintainer expressly
denied beforehand.
(and please don't make two weeks out of one; I don't count time without
feedback as very productive)
Yours
Thomas
Reply to: