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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
