[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers-public] Re: Patch²: Maintaining a patch for a debian p
[Savannah-hackers-public] Re: Patch²: Maintaining a patch for a debian package
Sat, 24 Sep 2005 23:19:30 +0200
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).
> > 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).
Changing the local version seems to trigger several issues. Maybe
there's a way to make local packages more prioritary than remote ones?
> Your other choice is just to place local packages on hold. Then when an
> upgrade is available, they will be listed in apt-get's upgrade list as
> 'held' packages, and you'll know it's time to rebuild. (I don't know
> how to automate this last bit. Exercise for the reader. ^_^)
Perhaps you could put them on hold in aptitude and let 'apt-src
upgrade' take care of upgrading the locally built packages. Source
packages will be displayed as "on hold" all the time, but that might
be considered more as a feature than as a bug ;)
I guess all this requires some more in-depth testing. Mainly, I think
apt-src's auto-patching is likely to produce conflicts on control
files (maybe also in dpatch's patches list).
That's not cron-apt yet, but it's already quite good :)