* Frank Mittelbach <[log in to unmask]> [2013-03-17 10:24:18 +0100]: Hi Frank, : your suggestion moves the workload to the CTAN team and I don't : think this is possible or sensible. If at all it needs to be a : solution that would do the register update fully automatically. I agree this moves workload to CTAN. There may be other ways to do this. : for that reason I don't think that the introduction of another aux : type file is warranted it would be something only needed for : managing the register but required all over the place. In contrast, : if you just have a formal specification, you could regularly build : the register by scanning across all dtx ctan files. Yes. That's another possible way. I think the main question is ``Who wants to be the prefix database manager?'' : >You can even make the kernel method reject existing prefixes. (Of course : >this would mean the method needs some way to access a local copy of the : >prefix database....) This may save the programmer precious time and : >troubles. : : I don't think we want to reject prefixes. We encourage not to use : existing ones, but there will be a time when this is needed and : wanted. And in some cases reuse to "extend" a code base will also : come into play. And how would you want to communicated with a : developer? if you issue a warning then if it is deliberate you will : need a way to get rid of it and such a warning should not show up : (imho) for a normal user. At least not against the register as such. : Perhaps on the level of what prefixes got loaded into the document, : but even then you would need to resolve a situation where (for good : or bad reasons) a prefix is shared deliberately between packages. When I wrote about rejection, I wanted to point out the possibility. Of course you can also inform the package writer. Informing the programmer is probably a better way. : so I guess food for more thoughts here, but a formal and parseable : interface on kernel level may be a good idea, even if we do not : directly use it to produce any external code or register : updates/queries from within TeX You could also introduce a kernel API to formally determine the package writer, contact details, package dependencies, and so on (all on a voluntary basis). This would really be useful information. Regards, Marc