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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
