Beberapa Petunjuk Mengompail Ulang Paket
Yang berikut ini, dari milis debian-user. Kali-kali, ada
manpaatnya.
--
Abdul Latip -- Angkasa Internet Junior Staff -- ANGIN.com
http://people.WebIndonesia.com/dullatip/ ----------------
KennyD (Mon, 12 Aug 2002 -- debian-user)
I tried to (re-)compile some debian packages on my machine using
apt-get source and dpkg-buildpackage - like I did for years, when I was
running potato - just to have optimized code for my AMD K7. But unlike
potato's apt, woody's apt reinstalls every selfcompiled package using
sources.list everytime I run apt-get upgrade, although it is the same
version. Like this:
apt-get source xfree86
cd xfree86-4.1.0
dpkg-buildpackage -rfakeroot -us -uc
dpkg -i ../xlibs_4.1.0-16_i386.deb # and some more...
apt-get upgrade
[..]
The following packages will be upgraded
xlibs
[..]
apt-get installs a new xlibs_4.1.0-16_i386.deb package from a remote mirror
or my local cache (I tried cleaning my cache, too!). Notice: it's the same
version I installed before with dpkg!
Has Anyone an idea what I could have missed, when I searched for an explicit
mention about that behaviour in the documentation? Is that apt's new
policy?
I think, it has nothing to do with priorities in /etc/apt/preferences, I
nearly tried everything. It's just as if APT regards official packages
as newer as a matter of principle.
I just found one solution (in theory!): making a
local package site including a Release.gz file and giving them a higher
priority through /etc/apt/preferences. But I don't want this.
Thanks for help!
-------------
Colin Watson:
=============
On Mon, Aug 12, 2002 at 05:23:06AM +0200, KennyD wrote:
> I tried to (re-)compile some debian packages on my machine using
> apt-get source and dpkg-buildpackage - like I did for years, when I was
> running potato - just to have optimized code for my AMD K7. But unlike
> potato's apt, woody's apt reinstalls every selfcompiled package using
> sources.list everytime I run apt-get upgrade, although it is the same
> version.
Add a new entry to the top of debian/changelog with a higher version
number.
> Has Anyone an idea what I could have missed, when I searched for an explicit
> mention about that behaviour in the documentation? Is that apt's new
> policy?
As far as I know apt has always behaved like this. Personally I think
it's a good idea, since it makes bug reports less confusing in the event
of self-compiled packages, and helps me remember which packages on my
system I built locally and which are official.
Cheers,
-----------------
Jamin W. Collins:
=================
> As far as I know apt has always behaved like this. Personally I think
> it's a good idea, since it makes bug reports less confusing in the event
> of self-compiled packages, and helps me remember which packages on my
> system I built locally and which are official.
Yea, but I think it would make more sense for the new package to be
created as more of a fork rather than an incremented version. I ran into
this myself a while back and now that I've read through more of the
maintainer and policy documentation it seems that it would make more sense
to create a new package name that "provides" the old package name. Sure
this is currently more work than creating a new changelog entry, but with
the changelog entry you run the risk of hitting the same version number as
the package maintainer and also of having your custom package
auto-upgraded (replaced) when the official package version is moved to
something higher than your entry. That is unless you put your package on
hold, in which case the higher version in the changelog entry is a rather
moot point.
Just my thoughts on the matter. I'll probably put together a quick how-to
when I work out how to go about the above with the least hassle.
----------
Simon Law:
==========
> Yea, but I think it would make more sense for the new package to be
> created as more of a fork rather than an incremented version. I ran into
The canonical way to prevent Debian packages from clobbering
your custom-compiled packages a version number of custom-21.1-1. No
normal Debian package will ever have a higher number, even when using
epochs.
[...]
OK. Let's say I have emacs21, which is at version "21.2-1". If I
compile a new version, with some different compilation options, I'm
going to version it "custom-21.2-1". Since "c" is larger than an
number, this will always be higher.
If you want to make sure that epochs don't clobber your
versions, you can version it "9:custom-21.2-1" which makes it unlikely
that the Debian official package will ever have a higher epoch than
yours.
Simon
-------
KennyD:
=======
> OK. Let's say I have emacs21, which is at version "21.2-1". If I
> compile a new version, with some different compilation options, I'm
> going to version it "custom-21.2-1". Since "c" is larger than an
> number, this will always be higher.
So, let me precise my actual problem: I just want the current version
recompiled. If there is (really) a newer package out there (i.e. with bug-
or security fixes) I want that newer package to be installed. This happens
not very often, since I prefer to run the stable release all the time. I'm
not making any important changes to the source code. I just want it to be
compiled for my machine using a gcc-wrapper to optimize the code. I am
highly interested in bug or security fixes.
If renaming the package version is really necessary, I suppose changing the
number 21.2-1 to 21.2-1.i686 solves the problem. But the foolish person,
which is me, thought, it won't be really necessary and 'apt-get -b source'
would perform well. Every documentation about that tells me so. No one
ever told me to use debchange or to edit debian/changelog. ;)
Probably you all are right and I've overseen this important part of APT's
policy (official overrules selfcompiled).
Thanks for help,
----------
Simon Law:
==========
On Mon, Aug 12, 2002 at 11:10:55PM +0200, KennyD wrote:
> If renaming the package version is really necessary, I suppose changing the
> number 21.2-1 to 21.2-1.i686 solves the problem. But the foolish person,
> which is me, thought, it won't be really necessary and 'apt-get -b source'
> would perform well. Every documentation about that tells me so. No one
> ever told me to use debchange or to edit debian/changelog. ;)
>
> Probably you all are right and I've overseen this important part of APT's
> policy (official overrules selfcompiled).
Oh. Then you definitely want something like 21.2-1.0.i686.
That way, if someone does an NMU on the package, then you will get
21.2-1.1 instead. (I think.)
Unfortunately, apt-get --build source doesn't have features that
allow you to do that. What you _can_ do is wait for apt-src/apt-build
which I hear will have copious amounts of nifty tweaking features.
-------------
Colin Watson:
=============
On Mon, Aug 12, 2002 at 01:04:14PM -0500, Jamin W. Collins wrote:
> Yea, but I think it would make more sense for the new package to be
> created as more of a fork rather than an incremented version. I ran into
> this myself a while back and now that I've read through more of the
> maintainer and policy documentation it seems that it would make more sense
> to create a new package name that "provides" the old package name.
Provides currently can't satisfy versioned dependencies, so this will
often be inadequate.
> Sure this is currently more work than creating a new changelog entry,
> but with the changelog entry you run the risk of hitting the same
> version number as the package maintainer
Add something like .0.local.1 to the end of the version number.
> and also of having your custom package auto-upgraded (replaced) when
> the official package version is moved to something higher than your
> entry.
You can always use a high epoch (e.g. "9:") at the beginning of the
version number to guard against that.
Cheers,
Reply to: