[Savannah-hackers-public] Re: Patch²: Maintaining a patch for a debian package

[Sylvain Beucler]

Sorry for the delay..

For the record:

> > > > >>>> I got an issue though, but I think it is related to glibc itself:
> > > > >>>> after installing the built source packages, aptitude/apt-get
> > > > >>>> absolutely want to upgrade them with the binary versions:
> > > > ::::: The following packages will be upgraded:
> > > > :::::   libc6 libc6-dbg libc6-dev libc6-prof
> 
> > > > >>>> Is this normal?
> 
> > > >>>> It is if you've not updated the changelog to be a new version, as
> > > >>>> apt-get will prioritise remote versions of a package over currently
> > > >>>> installed versions, if the metadata differs (as it will when you
> > > >>>> rebuild a package locally)
> 
> > >> Curiously this doesn't seem to happen for all packages. libc6 and
> > >> dtach, for example, will be replaced; mutt and dpatch won't (for stable).
> 
> >> That is weird. Check apt-cache policy for those packages, and see what
> >> it says. My understanding is that it should happen for any package,
> >> as locally install packages have priority 100, and nothing else gets a
> >> lower priority by default.
> 
> > Let's see :)
> 
> > dmc:~# aptitude upgrade
> > [...]
> > The following packages will be upgraded:
> >   dtach
> 
> > dmc:~# apt-cache policy libc6 # +0.1 trick
> > libc6:
> >   Installed: 2.3.2.ds1-22.1
> >   Candidate: 2.3.2.ds1-22.1
> >   Version Table:
> >  *** 2.3.2.ds1-22.1 0
> >         100 /var/lib/dpkg/status
> >      2.3.2.ds1-22 0
> >         500 http://ftp.fr.debian.org sarge/main Packages
> 
> > dmc:~# apt-cache policy dtach # apt wants to replace it
> > dtach:
> >   Installed: 0.7-1
> >   Candidate: 0.7-1
> >   Version Table:
> >      0.7-1 0
> >         500 http://ftp.fr.debian.org sarge/main Packages
> >  *** 0.7-1 0
> >         100 /var/lib/dpkg/status
> 
> > dmc:~# apt-cache policy mutt # apt says nothing for those
> > mutt:
> >   Installed: 1.5.9-2
> >   Candidate: 1.5.9-2
> >   Version Table:
> >  *** 1.5.9-2 0
> >         500 http://ftp.fr.debian.org sarge/main Packages
> >         100 /var/lib/dpkg/status
> > dmc:~# apt-cache policy dpatch
> > dpatch:
> >   Installed: 2.0.10
> >   Candidate: 2.0.10
> >   Version Table:
> >  *** 2.0.10 0
> >         500 http://ftp.fr.debian.org sarge/main Packages
> >         100 /var/lib/dpkg/status
> 
> > Apparently apt considers mutt and dpatch to be equivalent to the
> > remote versions, which is after what I want.
> 
> > Any clue? :/
> 
> Apt is acting exactly like you'd expect. You've managed to rebuild
> mutt and dpatch and get the same metadata. This is probably the reason
> binary NMUs have to increment the version by .0.1, as otherwise they
> won't actually be automatically selected... And the whole "can't upload
> versions that already exist." I guess.
> 
> I guess my question is, did you actually change dpatch and mutt, or just
> rebuild? It might be enlightening to debdiff the Debian and local .deb
> files for these two and see if they differ in a way that apt doesn't
> actually care about. (Which might be a bug... Or might be a feature)

# apt-src install & build - identical
$ debdiff mutt_1.5.9-2_i386.deb ../mutt*.deb
File lists identical (after any substitutions)

No differences were encountered in the control files

$ debdiff dpatch_2.0.10_all.deb ../dpatch*.deb
File lists identical (after any substitutions)

No differences were encountered in the control files

# apt-src install & build - NOT indentical
#  Note: the build system has vanilla libc6, not the patched one
$ debdiff ../dtach*.deb dtach_0.7-1_i386.deb
File lists identical (after any substitutions)

The following lines in the control files differ (wdiff output format):
----------------------------------------------------------------------
Depends: libc6 (>= [-2.3.2.ds1-21)-] {+2.3.2.ds1-4)+}

^^^ that's the problem, apparently

The control file says:
===
Package: dtach
Architecture: any
Depends: ${shlibs:Depends}
===


# The patched libc6
$ debdiff libc6_2.3.2.ds1-22_i386.deb ../libc6_2.3.2.ds1-22.1_i386.deb
File lists identical (after any substitutions)

The following lines in the control files differ (wdiff output format):
----------------------------------------------------------------------
Version: [-2.3.2.ds1-22-] {+2.3.2.ds1-22.1+}
Provides: [-glibc-2.3.2.ds1-22-] {+glibc-2.3.2.ds1-22.1+}
Installed-Size: [-15548-] {+15520+}


> > > >>> Is there a way to automatically update a locally modified package, or
> > > >>> can't we avoid a manual processing?
> 
> > >>> You could use dch -i to increment the version, or dch -n to increment
> > >>> the NMU version.
> 
> > >>> You could hack dch to have a --local-build switch, which increments the
> > >>> Debian version by 0.0.0.1 and will therefore be greater than the source
> > >>> you built, and less than a bin-NMU of the package. And then send the
> > >>> patch as a wishlist bug to devscripts. I think it'd be generally useful,
> > >>> to be honest.
> 
> > >> Some other tricky stuff happens when multiple binary packages are
> > >> built from a single source one - the versions in the binary packages
> > >> dependencies may need to be resynchronized (eg libc6-i686 Depends on
> > >> the same version of libc6).
> 
> >> Where this happens, I hope they're using the various macros provided for
> >> that sort of thing (${Source-Version} etc) so updating the changelog
> >> file is all that's neccessary. Nothing I'm rebuilding has shown any
> >> issues for .0.0.1 increments in the version. (Mind you, I'm not
> >> rebuilding anything libc. I like my system to keep running. ^_^)
> 
> > Hmmm:
> > Package: libc6-i686
> > Pre-Depends: libc6 (= ${Source-Version})
> 
> > Well I guess I missed something. Maybe apt-src tried to install the
> > built packages one by one... I have to retry and build (sigh :))
> 
> > (Note that I want my system running as well, it's just that
> > sysconf(SC_NGROUPS_MAX) returns 32 instead of 65536 and I need that
> > fixed :))
> 
> Erk. ^_^
> 
> Admittedly, it's prolly worth casting an eye over the shlibdeps-building
> stuff. You occasionally see bad NMUs when the NMUer forgot to check that
> the version-munging code to build a not-too-restrictive shlib deps
> version isn't prepared to parse NMU version numbers.
> 
> Happily, you more often see changelogs for packages which are _fixing_
> that type of issue. (eg. search for NMU in libc6's changelog.Debian. ^_^)

Unfortunately I'm not very familiar with NMUs and shlibdeps-building
:/ I guess I need to actually maintain a Debian package to understand
all those issues?

-- 
Sylvain