Hi! Some comments to things said on this bug report -----------------------------------------------
I don't think the current usage of the (exported) Package-Type field on existing packages is a fair criterion to use, and should not be considered to support any argument, as all of them have been or are maintained by me. Although AFAIR I did the change before the complaints from the d-i people, but just never reverted them, as I consider if something needs fixing that should be in dpkg. Responding to Russ comments, it's true that the d-i team's opinion on udeb matters should obviously be strongly considered, as its current main and only user (AFAIK). And that's why when I started the process to integrate udeb support back into dpkg, for example the udeb specific fields [0] got added w/o any hesitation. [0] Subarchitecture, Kernel-Version, Installer-Menu-Item. But when it comes to stuff that it's generic enough to be usable by the deb format or other variants, I just feel responsible to at least consider it's usage, format, naming, how it fits with the tools, etc. and possibly challenge previous decisions (which didn't seem to be entirely appreciated). Maybe I should not, and just accept anything other people develop on the side, w/o question, but then it would be akin to becoming a dpkg code monkey, which I'd rather not. Also I tend to think I'm open to be convinced by good arguments. Related to this, I've never fully agreed with the often over-usage of “bikeshedding” to demote some critical behaviour (or let's say attention to detail :), probably because I tend to consider all changes important (from typos, stylistic stuff, to bug fixes and new features, etc), they might deserve more or less attention, and might be more or less urgent though. A bit of (most probably biased) history --------------------------------------- So udeb has practically not been natively supported at all by dpkg, the only exception being the shlibs type, and the -u, --udeb parameter to dpkg-scanpackages. The rest has been supported via debhelper, which got knowledge of udeb before dpkg itself. As I mentioned on the bug [1] report, I think it's great that this kind of ad-hoc extension work on the format and tools is possible, and it's being used to improve Debian. But IMO at some point (sooner than later) it needs to get integrated back into the proper layers. [1] <http://bugs.debian.org/452273> I started checking what needed to be integrated back, generalized some of the current stuff, like deprecating dpkg-scanpackages --udeb in favor of ‘--type udeb’. Had some discussions with the d-i team (part of it posted on the bug log) mentioning my initial intentions which seemed to have no opposition at the time (otherwise I'd have not done the changes on the first place w/o further discussion, I just didn't see it coming those few additional bytes would be such a big deal), and then after a while added support for the udeb specific fields to dpkg-dev and started the process of adding support for the Package-Type field to some of the tools, which was supposed to be followed by tighter integration of udebs in dpkg and further discussion on if and how some other changes and fixes could be done to the udeb support in general (some of which I consider a byproduct of developing the support outside of dpkg). It seems there was some misscommunication and/or missunderstanding from both fronts (initial from the irc conversation and later on prolonged into the bug [1] report). Rereading the bug report it might seem I was strongly set on keeping the field exported, my main desire was to have the information there, as it seems useful to me and made the integration really clean, but not in field form necessarily, although that was the easiest to implement. I could have probably reverted the exporting of the field before further discussion, which might have seemed less imposing, but given the bulk of the d-i udebs were not using it, it didn't seem urgent to me. What I was actually trying to do was to get to a possible solution that could work for both sides (I might have probably not expressed this clearly), but that seemed to be just annoying people, and I got the perception that there was no compromise possible at all, 0 bytes was the only valid option, not even for example trying to trim down size from some other place to compensate for the new addition. So I gave up, even trying to propose other solutions, reverted the warning, and let stuff as it was (to possibly be discussed later on) due to the tone the conversation had headed and because it was pretty late in the release cycle. Some possible solutions and benefits ------------------------------------ The possible solutions I've had in mind, some more or less desirable than others, just for reference: - Additional type file in control.tar.gz (> size, around 37 bytes as it needs two new 512 byte tar blocks, mostly with 0s but still, obviously not acceptable). - Normal field (already rejected, around 10 bytes). - Renamed shortened field (probably not acceptable either). - Additional line w/ "udeb\n" in debian-binary ar member (5 bytes), or if 5 would be still too much "U\n"/"u\n" (2 bytes). This OTOH would require way more code changes as the field would need to get stripped from the control file and added to debian-binary, and the reverse done on extraction. - Normal field, switch udeb data.tar to use lzma/xz to compensate for the additional size, with a compression level making the extraction use a reasonable amount of memory (few MiB). - Others... - Ignore it only for udeb. Other benefits: - (somewhat minor) dpkg-name can actually do its work, w/o relying on the existing file name. - some other stuff I commented in <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452273#90> Conclusion ---------- I'd rather not have gotten dragged to the tech-ctte, as personally I consider any such situation a failure on both sides of an argument, and a pretty aggressive move. But then, more eyes and minds on an issue tend to always be good, it only depends how they are brought in, though. Anyway, I'd rather just make dpkg-dev special case udebs and not output the field to the binary, even if I think that will imply lose of automation and better integration among others, than a possible solution shoved down the d-i team throat which they seem to consider completely unacceptable (even if probably that outcome is unlikely given the stance of some of the ctte members, but still), or my throat. Obviously I'd abide by any decision by the ctte, but I'd be happier by never having to be subject to one (on either side). So given this, that's what I'm going to be doing for next dpkg upload targeting sid (to be clear discard the field *only* on udebs). Also I don't expect to have the energy to be initiating any further udeb integration in the near future, but other people are welcome to, though! regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
