Re: Correct way to do binary-only NMU?

[Tollef Fog Heen <tollef@add.no>]

* "Christian T. Steigies" 

| On Thu, Feb 22, 2001 at 12:44:24PM +0100, Tollef Fog Heen wrote:
| > * "Christian T. Steigies" 
| >
| > | debian/changelog is not in source of the package. Is that really written in
| > | the developers reference (too lazy to check that now)?
| > 
| > Of course.  If you change the source, you need to bump the version
| You mean of course, yes?

No, it was a remnant from my first sentence.  So much for reading
through the mail before sending it.

| > number.  That is a _source_ NMU, since we need to able to build the
| > packages from the source we have around.
| > 
| > A binary NMU should not touch the source.  Remember - a buildd
| > building and uploading is, technically, doing an NMU.
|
| When I rebuild a package to fix dependency problems (recent example, aview
| in potato/m68k depended on a library which was not in potato, so I rebuilt
| aview with the potato libraries, changed nothing in the source, only bumped
| up the version number, with sbuild, which adds a changelog entry to say just
| this: no source changes) that is not ok in your eyes?

>From the developers reference:

    A source NMU is an upload of a package by a developer who is not
    the official maintainer, for the purposes of fixing a bug in the
    package. Source NMUs always involves changes to the source (even
    if it is just a change to debian/changelog).  This can be either a
    change to the upstream source, or a change to the Debian bits of
    the source.

    A binary NMU is a recompilation and upload of a binary package for
    a new architecture.  As such, it is usually part of a porting
    effort.  A binary NMU is a non-maintainer uploaded binary version
    of a package (often for another architecture), with no source
    changes required. There are many cases where porters must fix
    problems in the source in order to get them to compile for their
    target architecture; that would be considered a source NMU rather
    than a binary NMU.  As you can see, we don't distinguish in
    terminology between porter NMUs and non-porter NMUs.

You fall between two chairs - as noted in 7.4.3:

    What if you are simply recompiling the package?  In this case, the
    process is different for porters than it is for non-porters, as
    mentioned above.  If you are not a porter and are doing an NMU
    that simply requires a recompile (i.e., a new shared library is
    available to be linked against, a bug was fixed in debhelper),
    there must still be a changelog entry; therefore, there will be a
    patch.  If you are a porter, you are probably just doing a binary
    NMU.  (Note: this leaves out in the cold porters who have to do
    recompiles -- chalk it up as a weakness in how we maintain our
    archive.)

But the situation is clarified in 8.2:

    Sometimes you need to recompile a package against other packages
    which have been updated, such as libraries.  You do have to bump
    the version number in this case, so that the upgrade system can
    function properly.  Even so, these are considered binary-only NMUs
    -- there is no need in this case for all architectures to
    recompile.  You should set the version number as in the case of
    NMU versioning, but add a ``.0.'' before the the NMU version.  For
    instance, a recompile-only NMU of the source package ``foo_1.3-1''
    would be numbered ``foo_1.3-1.0.1''.

    The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B
    -mporter-email.  Of course, set porter-email to your email
    address.  This will do a binary-only build of only the
    architecture-dependant portions of the package, using the
    `binary-arch' target in debian/rules.

| Technically you may be right, but practically we (well, at least I) do it
| like this, just to get things working. Its not necessary that all arches
| rebuild hundreds of packages, only because m68k only recently switched to
| glibc2.2. And I think thats exactly the reason for the NMU version
| numbering. After all, we just recompile the package with a new libc library
| installed.

Yes, you are right.  But there are not problems with hundreds of
packages, are there?

| Maybe the Developers reference should be clarified, or will I be
| expelled from the project now?

I guess the Developers reference should be clarified (the 7.4.3 that
is, as it seems to be clarified in 8.2).

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.