Bug#575059: Should Package-Type be included in udebs or not?
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
Reply to: