Hi, Quoting Josh Triplett (2015-11-01 21:33:19) > "Binary" seems a bit excessive for several reasons. First, it seems > redundant with the "Source" entries in Packages files; we don't > necessarily need a two-way cross-reference at all here. And second, we > could assume that a missing entry means "same as Package". That rule > (source equals binary) would work for 13364 of 24097 packages in Debian > today, and potentially more if other single-binary packages ensured > their source and binary names matched. > > For that matter, Binary and Package-List seem redundant. (And > Package-List doesn't seem like end-user metadata; it seems like > something only the Debian infrastructure needs.)
You can read about the original purpose of the Package-List field here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619131 It has recently been extended to also carry information about the build profile formulas that the binary packages a source package builds carry and there are talks to also let it contain non-architecture specific, unversioned binary Provides information. You would probably call this yet more duplication because all this information can be retrieved from the Packages file. But adding this information to the Sources file is useful because in a bootstrapping scenario your Packages file is empty. > Do we really need fields like Build-Depends, Testsuite, or Standards-Version > pulled out of the package itself and placed into the Sources file? Why do we > need to read those without the source package? (Note that tools that form > part of Debian infrastructure could work from UDD or similar; the question is > why those fields are needed on an end-user system that downloaded the Sources > file.) Why does an "end-user system" have a deb-src line in its /etc/apt/sources.list in the first place? I think I don't understand yet what use case you want to optimize for. And what do you consider "Debian infrastructure"? I like the Sources file precisely because it can be downloaded by anybody (in contrast to UDD for which one has to use a mirror right now). If information like Build-Depends or the Package-List field gets removed from the Sources file, then it should remain in a place that is as easy to access as the Sources file is right now. What exactly are you proposing? Suppose we'd have a Sources.full and a Sources.minimal. The latter would only carry the fields necessary for apt to be able to download a dsc while the former would be like today's Sources file. Would that not again mean lots of duplication because all information in Sources.minimal is part of Sources.full? So this would not help our mirrors (they'd actually now have to store more) but it would help our users who would now have a few MB less on their systems. Or you could just not have Sources.full on the mirrors but only distribute Sources.minimal. But if you do that, please, please, please make Sources.full just as easily accessibly as Sources is right now, including getting snapshotted and available for all suites, architectures and ports. > In the Packages files for binaries, we could eliminate a *massive* amount of > redundancy by having a dedicated Packages file for "all", to avoid > duplicating entries into every architecture's Packages file. That should not > significantly increase overhead for end-users, and for any user of multiarch > it'll decrease overhead. A quick check on amd64 shows that splitting out > "all" into a separate Packages file would not change the combined > uncompressed size at all, should not change the pdiff size at all, and would > increase the combined compressed full-download size by 94k, from 9957k to > 10051k, an increase of less than 1%. That seems reasonable in exchange for > eliminating 12 duplicate copies of the 4396k used for "all" Packages files, > times suites (oldstable/stable/testing/unstable/experimental), and that > doesn't even count unofficial architectures, or snapshot.debian.org. There is a thread about this on debian-dak@l.d.o: http://lists.debian.org/20151030145625.GB14516@crossbow cheers, josch
signature.asc
Description: signature
