On Tue, Sep 27, 2005 at 05:39:59PM +0200, Sylvain Beucler wrote:
> On Mon, Sep 26, 2005 at 12:15:11AM +1000, Paul TBBle Hampson wrote:
>> On Sat, Sep 24, 2005 at 11:19:30PM +0200, Sylvain Beucler wrote:
> >> On Sat, Sep 24, 2005 at 12:39:14AM +1000, Paul TBBle Hampson wrote:
> >>> On Fri, Sep 23, 2005 at 03:10:34PM +0200, Sylvain Beucler wrote:
> > > >>>> 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)
> > >>> 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. ^_^)
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
Attachment:
pgpeHbcQTsq0l.pgp
Description: PGP signature