Re: Patch²: Maintaining a patch for a debian package
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? :/
> > >> 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 :))
> > Changing the local version seems to trigger several issues. Maybe
> > there's a way to make local packages more prioritary than remote ones?
>
> You could prolly put an apt-preferences entry so that packages from
> /var/lib/dpkg/status
> get a higher priority than 100, but that strikes me as a disaster
> waiting to happen, although I can't actually explain why.
>
> Frankly, I just maintain a directory in my home directory called
> LocalDeb and build everything in that by hand. (Now using pbuilder-uml
> so I can trim the number of -dev packages floating around my system.)
Yeah, I guess if dpkg/status has a default low priority, there must be
reasons :)
Thanks,
--
Sylvain
Reply to: