On Sunday, 4 October 2026 00:30:19 Central European Summer Time you wrote: > The other day I noticed that this packages has modules in the Dpkg:: > root namespace. This means dpkg itself would not be able to use those > names currently (or in the near future). And although I don't have > immediate plans or need for those names, I've had in mind for a while > to start adding modules for the specialized file formats, so the > Dpkg::Copyright hierarchy would get used by dpkg itself in the future. > > The current Dpkg:: modules provided by this package do not seem like > they could be integrated into dpkg proper anyway, given the API patterns > and its dependencies. So to avoid issues, conflicts and confusion, it > would be nice if these got moved under the Config::Model namespace? Or > was there some specific reason to use the root Dpkg:: namespace?
The main reason not to put these files under Config::Model is: these modules can be used outside of Config::Model to scan copyright or to store grants in Dpkg::Copyright::Grant::* (although I forgot to add doc for these modules...). I'm willing to extract them out of libconfig-model-dpkg-perl if needed. That said, I can move them out of Dpkg hierarchy, but what should be the new hierarchy ? (naming is hard...). May be DpkgX ... I'm open for suggestions. All the best
signature.asc
Description: This is a digitally signed message part.
