Re: The noudeb build profile and dh-only rules files
On Mon, Jul 08, 2019 at 07:28:50PM +0100, Colin Watson wrote:
>
> Per my other reply, you may find that it isn't that painful after all
> once you find the right approach. For instance, while a separate udeb
> build pass does make
> https://salsa.debian.org/ssh-team/openssh/blob/master/debian/rules a
> little bit more complicated, I wouldn't say it's something I find myself
> having to think about very often.
Thanks, that's really helpful. One of the really frustrating things
I've found about trying to use dh is that there is a real lack of
examples which are more complicated than:
#!/usr/bin/make -f
#
# See? dh is easy-peasy!
%:
dh $@
Sure, there are few a examples using one or two override declarations,
but trying to use dh on a non-trivial package is.... non-obvious,
given the current documentation. Some more advanced tutorials, or
some links to good examplars of how to use dh in "real world",
non-trivial packaging setups, would be really good. It looks like
openssh is a good example, but I'm sure they must be others.
> > P.S. If anyone thinks that increasing the size of the debian
> > installer by 145k is unacceptable, please let me know now....
>
> This is something you'd need to run past debian-boot@, as there may well
> be particular images for which it still matters (I haven't kept up, but
> it's certainly something they'd want to be informed of).
Ack, I'll do that. I did try to do some research, and I think I saw a
netinstall image which was 48 MiB, but I didn't see anything smaller.
Of course, I haven't checked all architectures, so checking with
debian-boot would be good.
> Oh, and apologies if this is obvious, but the other reason a separate
> udeb build pass may be necessary is if certain configure options make
> the code actually not work in the context of d-i. This is the case for
> openssh (for example, it builds an sshd that can be used as part of
> d-i's network-console feature, but PAM wouldn't work in that context).
> I don't know whether it's the case for e2fsprogs.
Yeah, it wasn't the case of e2fsprogs not working (I've always tried
to make e2fsprogs very self-contained with an absolute minimal number
of dependencies, since it has to work before /usr is mounted.) It was
doing things like disabling gettext/NLS which was responsible for the
bulk of the 145k decrease in size, IIRC.
As I said, back in the days of installation floppies, it was clearly
worth it to do a second pass build just to save bytes. But these
days? Realistically, e2fsprogs-udeb has been growing in size as ext4
has become a more featureful file system; for example, between Debian
Jessie and Debian Buster, e2fsprogs-udeb has grown by 142k. And back
in the ext2/ext3 days of installation floppies, before e2fsprogs
supported 64-bit block numbers, ext4 features like extents, inline
data, bigalloc, metadata checksums, etc., e2fsprogs-udeb was even
smaller.
- Ted
Reply to: