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 via email to