Drew Parsons <[EMAIL PROTECTED]> writes:
> Running on the theory that it might help speed up my Pentium II system
> (debatable, but that's beside the point), I've tried
> recompiling a selection of packages with pentium optimisation, downloading
> the debian source and running `./debian/rules binary`.
> However, after having done this, every time I `apt-get upgrade`, these
> packages get downloaded from the debian ftp server
Ok, 1) this isn't really a laptop issue, and 2) yes, you're correct.
Apt will assume you want the most up-to-date package, and, since the
package on the ftp server is newer than the one you built, it gets
preferred. The easy solution is to put the package on hold -- but
this has the disadvantage that you *don't* get newer versions at all.
Actually, it's not really about "newer", it's about having a
version number that sorts later, so, one possibility is to use a
special version number that will always sort later. This is the trick
suggested for custom kernels. Thus, you could make bzip 0.9.5d-my2 or
even my-0.9.5d-2. The former would stick until a new upstream
release, the former would stick basically forever (unless the debian
maintainer increases the "epoch", which we won't get into now).
This doesn't just happen with pentium-optimized packages. It happens
any time you make a local custom version of a package.
What I'd really like to see is a way to flag a package as "maintained
locally". Ideally, this would make apt download the source when a new
version appears, merge it into your local CVS repository, wait for you
to resolve any conflicts, then build and install the package. There's
a little bit of work involved for that to happen though.... :)
For now, putting the package on hold is probably your best bet.
cheers
(This thread really belongs on debian-user, so I've set the reply-to
field.)
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or [EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
