Bug#688041: Please confirm
Hi, Norbert.
On 12.10.2012 03:06, Norbert Preining wrote:
> You don't see the conceptual difference between collection splitting
> and splitting a class of files (DocFiles) of packages.
In other words: You insist, that debian packages must not correspond to
TeX Live packages (which are part of a collection).
The effect on whether this bug can be solved - at all - is the same.
>> I have already proposed a solution. But maybe it was not detailed
>> enough? Not that anyone would have told me...
>
> Still you haven't provided a list of TeX Live packages that should
> go into the new collection, nor a new name,.
And you haven't understood my proposed solution. Maybe you read it again.
I did not say a word about making a new collection.
> Everything you say like:
>> By a new configuration option in all/debian/tpm2deb.cfg selected
> ...
>> be automated in the scripts tpm2deb-source.pl and
>> all/deb/tpm2debcommon.pm. Those scripts have access to any dependency
>
> Are as commonplace as possible.
You're mistaking abstraction for commonplace. I have outlined the
solution, not written the code. If that solution is already denied, the
code cannot possibly have a chance.
> Of course we know which are the
> scripts and configuration files for our packaging.
>From your last mail, you questioned that I know. So for you I had to be
extra specific. If I hadn't named the files, you probably would have
accused me of making "commonplace". Oh, you already did...
> What Frank asked is getting your fingers out of .... and write code,
> provide patches, be constructive.
So that you can be as destructive as before and reject the patch because
it splits collections into packages? No, thank you.
> But if you want something and provide *CODE*, then we have much
> more reason to consider it.
You *MIGHT* have much more reason to consider it, but there is no guarantee.
I expect you to reject the patch. Reason: It splits collections into
packages. (or you just ignore it)
Unless I'm convinced you don't do that, I will not put ANY more work
into that.
>> 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.
>
> And who cares for the necessary replaces ... etc etc.
So, finally a constructive comment on your side... I'm impressed.
However you haven't commented on whether the premise is true or false:
"If it is a problem that new debian packages would be generated as
frequently as new fonts are added".
I don't think that would be a problem. The new fonts would get new
packages sooner or later anyway, so they can as well be created the
moment they are added.
But in case you'd think otherwise I added this part as a solution, that
would be suboptimal but still better than the current state.
The -others package would have a warning that maintainers should make
dependencies on that package only with the specific version number and
request that the font they are depending on should be exposed as a
separate package.
Users who explicitly install that package (other than as part of the
collection's dependency package) would (by package description) be well
aware that they have no guarantee that the font they want will still be
in the package in the next release, but if it is not, they will have a
guarantee that there is a stable separate package for the font (unless
of course, if the font is removed from TeX Live in the first place).
Yours
Thomas
Reply to: