Guillem Jover <guil...@debian.org> writes: > On Sat, 2017-06-24 at 09:57:33 -0700, Russ Allbery wrote:
>> - The list of archive sections and their descriptions > I think this belongs on each archive providing those, alongside the > other archive metadata. And I'd rather see the involved parties > defining an appropriate file to provide so that any downloader which > has to fetch the matadata anyway would use instead of hardcoding it. > Using a file from policy does not seem useful to me, because it would > mean software would need to depend on such policy provided package, > and if you are going to mix and match repos, you really need the > metadata from the archive you are pulling from. > In addition the text in policy states that the canonical list is > maintained by the archive anyway. :) I don't see how this would work. The program would dynamically retrieve the list of sections every time it ran? This seems like a bad idea, and even impossible in a lot of situations (off-line development work, for instance). We maintain a list of archive sections in Policy anyway, so it's easy for us to provide this list in a machine-readable format as well. (Well, we don't have the descriptions, but that's not hard to add and doesn't really add much additional maintenance work.) I think it's fine that a debian-policy-data package only provide information for the Debian archive. The same is also true of the virtual package names, of course; some other archive may have different virtual packages too. Programs that want to work with various different package archives will need to know how to obtain this data from multiple sources. The intent is to provide a tiny package that others can easily depend on without much overhead. >> - The list of valid Debian control field names (by type of control file) > This one, I'm uncertain, but I'd tend to think it is partly in a similar > situation to the previous one. > For example dpkg contains already such a list (provably more > exhaustive) in Dpkg::Control::Fields, and I don't see making dpkg > depend on an external list, because dpkg is being used beyond Debian. This was just an idle thought of mine, and maybe it doesn't solve any real problems. > For the equivalent in policy I think I see where you are coming from, > and I think it would be nice to have most of policy in a declarative > format that could be used by linters, or some parsers, but if that means > it's going to make those somewhat Debian-specific it might not take > off. I'm in general fine with the things provided by Debian Policy being Debian-specific. That, in my opinion, is the point of the package. If some other distribution wants something equivalent, they can certainly fork Debian Policy or write their own separate document that supplements Debian Policy, and maintain corresponding data files. > The list of common licenses perhaps. Other things that come to mind > could be perhaps a file with common regexes to validate things that > policy specifies, say package names, version strings etc. Precisely > because those can and do diverge from what dpkg accepts for example. Yes, those would also be interesting. > Valid pathnames, etc, and as I've mentioned above ideally all of policy > would be available in a declarative format, but that'd be a pretty huge > undertaking. But then it might make sense to do a quick poll and ask > whether people would use any of this, because otherwise it seems perhaps > a bit like a waste. Indeed. The virtual package name list has a specific use case already, and people suggesting using sed scripts to parse files from the debian-policy package to generate it right now, so maybe we should just start there and see if uses of the other data actually materialize. Lintian is a large possible use case, but Lintian already has mechanisms for gathering and maintaining this data internally, and Lintian may not want to depend on a debian-policy-data package for various reasons (it makes lintian.debian.org a bit harder). > I don't think I have a direct use for any of the above anyway, but I > also think I'd prefer YAML, because it is more human readable. But not a > strong objection in any case. I have a professional aversion to YAML because the security properties of YAML are so awful. I wish everyone would just use TOML, but unfortunately it's not at a 1.0 version yet and is not as widely supported by default as JSON is. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
