On 13698 March 1977, Paul Wise wrote: > Various places in Debian infrastructure (QA especially) hard-code > aspects of the Debian archive (suite, code, component, arch names etc). > This is a problem because after new suites or architectures are added, > we have lots of places that need to be updated. Most of them can be > fixed (help needed), however Debian does not provide information about > which repositories are available where, which suites are provided by > them, nor any information about the relative order of those suites, nor > any information about which suites are archived.
Most of that information can be extracted from projectb/obscurity, so we should provide that. Not all, so we either extend the database or maintain a second file and merge them. > Detached OpenPGP signatures so that the information is easily and safely > verifiable; safe verification of inline signatures have been shown to be > harder to implement in the past. If we export it archive side it (IMO) ends up on the mirror, so we can either just sign it with the archive keys and put the sig beside it, or have the files listed in Release files. I prefer Release files. > Automatically generated based on the dak database/configuration so that > it never gets out of date. That only works for parts of the information, unless we extend the db. (Which is a valid option). > Generated on a per-repository basis so that consumers get the data they > are interested in. Here I mean one for ftp.d.o/debian and one for each > of the archive.d.o/* repositories. archive.d.o is no longer in any database. So for all of those we have to write them once by hand. If we have them exported from dak in the future, all future archivals will automatically have them. > Be machine-readable by a variety of languages (including shell and more > capable languages), deb822 format seems best here. Works. > Be named Suites (in the dists dir) & Repositories (on ftp-master). Or just one file that lists em all? Though I think it depends what all goes into. > The data needed for the Suites file is basically just a list of suite > names but maybe we need some other information like the relationships > between them? Metadata of the suites themselves should be in the Release > files as usual. If we take it in combination with Release files, and not standalone, then sure. The small set you list above we do have in database (tables suite and version_check). > The data needed for the Repositories file is basically just a list of > repositories canonical URLs and if the repository is active or not. Thats also simple. > Perhaps it would be useful to have names fields or other data too? I think it would be useful to come up with an actual list of what exactly we all want to have in the file(s). Following that ubuntu link isn't too helpful I think. Except that it currently sounds easy enough for the archive side. -- bye, Joerg > What would you do if you wanted to retire from the project? This is far easier than to get in! ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
