Debian Packaging Tutorial update

As previously announced, I’ve been working on a Debian packaging tutorial. It is composed of about 60 slides providing a throughout overview of Debian packaging.

It now reached the point where I consider it ready for use, and I am looking forward to reviews and comments.
The document is split into 4 different PDFs:

And of course, it can be found on git.debian.org:
git clone git://git.debian.org/collab-maint/packaging-tutorial.git

16 thoughts on “Debian Packaging Tutorial update

  1. Two comments about the style and technical implementation:
    1. you should use the package pgf and its \pgfdeclareimage/\pgfuseimage for the logo that is repeated on each slide: it would include it only once in the PDF file and refer to it each time instead of copying it for each page;
    2. underlining is usually not recommended, even for titles.

  2. @Tanguy:
    for pgfuseimage, fixed, but it didn’t have any real influence on the size of the generated PDF.
    for the underlined titles, I’m not convinced, let’s see what others think. I against using a colored background for the titles, since it uses a lot more ink when printed.

  3. @lucas:
    For the underlined titles, I think a line separating the title from the content, with a lenght independent to the title length, would be a better choice.

  4. New remarks:
    * thanks for making me discover debi(1) which I did not know;
    * source format 3.0 (quilt) is not the future, it is the present;
    * perhaps explicitly state that DEP-3 (by the way, it is DEP-3, not DEP-3 the official way to write it, I tihnk) headers are to be put above the patch content, which is an area that diff/patch leave free for commenting the patch, and maybe include the beginning of the patch in the example too: this may not be obvious (it was not, for me).

  5. 14. Files in debian/
    ‘Most of the files use a format based on RFC 822’ is just not true. The only common files in this format are control and (optionally) copyright.

    18. Architecture: all or any
    It may be worth saying explicitly that a source package can generate a mixture of arch:all and arch:any. This is not possible with RPMs which some people might be used to (or it wasn’t when I last tried).

    21-22. debian/rules using debhelper
    This has a fair amount of junk – commented-out lines and redundant dependencies – which I think detracts from the example.

    23. CDBS
    Not sure why you repeat so much FUD against CDBS.
    It would be more helpful to link to the presentation at and

    25. Classic debhelper vs CDBS vs dh
    ‘Market share’?! Maybe ‘mind share’.
    ‘Which one should I learn? … Probably all of them’. I don’t agree. You need to know what sort of things debhelper and CDBS cover, and you need to be able to recognise the different styles of makefile. Beyond that, read the docs when you can. Well it works for me, anyway.

    33. Patch systems
    As Tanguy says, the 3.0 (quilt) package is the present. It should be mentioned first.

    35. Doing things during installation and removal
    You should mention that debhelper covers the most commonly required actions. Also possibly mention triggers.

    39. Several ways to contribute to Debian
    Might be better to put the preferred contributions (adoption / joining a team) higher.

  6. > * source format 3.0 (quilt) is not the future, it is the present;

    fixed

    > * perhaps explicitly state that DEP-3 (by the way, it is DEP-3, not
    > DEP-3 the official way to write it, I tihnk) headers are to be put
    > above the patch content, which is an area that diff/patch leave free
    > for commenting the patch, and maybe include the beginning of the patch
    > in the example too: this may not be obvious (it was not, for me).

    fixed

    > Can you add a date ? outdated docs on the Internet is a PITA.

    fixed

  7. > 14. Files in debian/
    > ‘Most of the files use a format based on RFC 822′ is just not true.
    > The only common files in this format are control and (optionally) copyright.

    Fixed with s/Most of/Several/

    > 18. Architecture: all or any
    > It may be worth saying explicitly that a source package can generate a mixture
    > of arch:all and arch:any. This is not possible with RPMs which some people
    > might be used to (or it wasn’t when I last tried).

    Added

    > 21-22. debian/rules using debhelper
    > This has a fair amount of junk – commented-out lines and redundant
    > dependencies – which I think detracts from the example.

    It’s the default template generated by dh_make. Can you suggest a better example?

    > 23. CDBS
    > Not sure why you repeat so much FUD against CDBS.
    > It would be more helpful to link to the presentation at
    > http://meetings-archive.debian.net/pub/debian-meetings/2009/fosdem/slides/The_Common_Debian_Build_System_CDBS/
    > and http://meetings-archive.debian.net/pub/debian-meetings/2009/fosdem/low/The_Common_Debian_Build_System_CDBS.ogg

    The first item “still a lot of redundancy between packages” was ambiguous, I’ve rewritten it to say:
    “With debhelper, still a lot of redundancy between packages”.

    Regarding the presentation, I find the cdbs documentation very good, and I’m not sure of the talk really brings anything more.

    Was there other “FUD” you were referring to?
    Even if i’m a CDBS fan (user since 2006), I think it’s fair to say that people are migrating to dh.

    > 25. Classic debhelper vs CDBS vs dh
    > ‘Market share’?! Maybe ‘mind share’.

    Fixed

    > ‘Which one should I learn? … Probably all of them’. I don’t agree. You need
    > to know what sort of things debhelper and CDBS cover, and you need to be able
    > to recognise the different styles of makefile. Beyond that, read the docs when
    > you can. Well it works for me, anyway.

    OK, I’ve rewritten it do:
    \item Which one should I learn?
    \begin{itemize}
    \item Probably a bit of all of them
    \item You need to know debhelper to use dh and CDBS
    \item You might have to modify CDBS packages

    > 33. Patch systems
    > As Tanguy says, the 3.0 (quilt) package is the present. It should be mentioned first.

    it doesn’t really make sense from a pedagogical POV. But I’ve emphasized 3.0
    (quilt) by putting the whole line in bold.

    > 35. Doing things during installation and removal
    > You should mention that debhelper covers the most commonly required actions.

    added

    > Also possibly mention triggers.

    added, but at the end of the doc

    > 39. Several ways to contribute to Debian
    > Might be better to put the preferred contributions (adoption / joining a team) higher.

    done

    Thanks!

  8. CDBS reference mentioned above is interesting resource for people to learn CDBS when people need to deal older existing packages made with CDBS. CDBS’s design goal for simpler debian/rules file was right one but now that dh does as good job with better technical details, I think tutorial should focus on dh.

Comments are closed.