On Sat, 2022-12-17 at 08:35:02 -0800, Russ Allbery wrote: > (That said, and this is only personal preference and I don't feel that > strongly about it, I usually err on the side of creating lots of bugs so > that there can be roughly one bug per patch. It can make it a bit harder > to track things if there's one bug following a bunch of semi-related but > separable changes. Unfortunately, the BTS doesn't support the concept of > a hierarchy with a tracking issue and a bunch of underlying implementaton > issue very well.)
(Right, personally I don't think I'd split one bug per patch, as long as the patch is covering the same thing, perhaps. In this case I pondered about opening a new one, but given the initial discussion and context was here it seemed best to keep it together. Should have perhaps split the stanza stuff into another report, though. :) (In any case, hope this is all not too inconvenient!) > Guillem Jover <guil...@debian.org> writes: > > And for some reason I think I also got the impression, even though > > the stanza changes had been committed, they could still be backed out. > > (BTW I've now gone over the wiki and updated all paragraph references > > that applied to stanza.) > > I'm personally happy to stick with stanza. Sorry, rereading that paragraph it seems not clear on what I was trying to convey. :) I meant that because I thought this could be backed out until an upload, I guess subconsciously postponed further changes for this (both in dpkg and here) based on that. Should have asked. > > I also recalled another term that has always seemed very confusing in > > context: «control information files» or «control information area». For > > example in a sentence such as “the control file is a control information > > file in the control information area in a .deb archive”. :) This also > > seems confusing when some of the files in the .deb control member are > > not really “control files” with a deb822(5) format. > > > My thinking has been going into calling these as the «metadata files», > > and being located in either the «metadata part of the .deb archive» or > > explicitly the «control member of the .deb archive», in contrast to the > > filesystem part. In dpkg I'd be eventually switching to meta/metadata > > and fsys/filesystem, from control or info and data. I've added a patch > > with the proposed change, but again nothing set in stone, and I'm again > > open to discussing pros/cons of this. > > I like metadata file, but I think I prefer talking about the "control > member" than the "metadata part" because it more closely matches what one > sees if one takes the *.deb file apart. But I haven't looked at your > diffs yet. Probably more clear currently, yeah. To expand on the above, my thinking has been for example that if we ever have a deb 3.0 format, I'd probably like to name the members, something like: «meta.tar.*» and «fsys.tar.*», and that's also what I've kind of been moving the dpkg internals to (functions, structs and similar). Also as part of the file metadata work, I've also have pending splitting the dpkg db info/ dir into a dir that contains things shipped by the .deb, and a dir for stuff generated by dpkg itself, so that they cannot conflict or get overwritten or need to be taken into account doing any of that. Thanks, Guillem
