Bug#575059: Should Package-Type be included in udebs or not?
Guillem Jover <guillem@debian.org> writes:
> 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.
I'm sorry for the way I presented that in my original response. You're of
course completely correct: when there are design concerns and issues, and
when a feature could or should generalize, taking some time to work out
the best architectural design is exactly the right thing to do. Also, I
completely agree that you shouldn't have to feel like you're just a dpkg
code monkey.
I was conflating several things together and was mostly looking at the
argument over whether or not the Package-Type contents should be included
in the *.deb, not the overall design and related issues that you were
discussing. And even still, that was a poorly chosen term on my part.
> 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>
FWIW, I entirely agree with this from the Policy perspective as well. I'd
love to see udebs fully documented and fully supported by our native tools
and procedures. Among other things, it will make it easier for projects
that require udebs to come up to speed.
> 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.
Hopefully, it doesn't have to be an aggressive experience. The last thing
we want to do is shove anything down anyone's throat, and usually we can
end up just being mediators and helping getting the conversation started
again.
> 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!
My feeling here is that proper integration of udebs with the rest of the
infrastructure may require a few compromises to the current design, so I
think it's something that would be best tackled with someone on the d-i
side who was actively interested in making udebs less of a special case
and felt like that was the right architectural decision, and had time to
put some effort into that. It sounds, from this bug log, like a lot of
benchmarking of sizes and the impact of size changes, and possibly some
size versus performance tradeoffs like other compression methods, would be
vital to that work.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: