How do I prevent rebuilt packages from being upgraded?

Posted by tong on Mon 16 Jan 2006 at 14:11

What is the correct right way to rebuild package in Debian whilst preventing those packages from being downgraded, without applying a hold upon them?

I've increase the package version number in the packages I've rebuilt, with the intention that they will not be updated when I use "apt-get upgrade".

Unfortunately when I try this I receive the error:

The following packages will be DOWNGRADED:
  dvd+rw-tools nget

What's the best approach to custom build packages so as not to interfere with upgrades?

In order not to be overwritten by apt-get, I increased my custom build packages by .1, as shown below:

$ apt-cache policy dvd+rw-tools
dvd+rw-tools:
  Installed: 5.21.4.10.8-1.1
  Candidate: 5.21.4.10.8-1

$ apt-cache policy nget
nget:
  Installed: 0.27.1-1.1
  Candidate: 0.27.1-1

But still apt-get insists that I have to downgrade them.

 

 


Posted by jooray (85.216.xx.xx) on Mon 16 Jan 2006 at 15:23
[ Send Message ]
You should hold them and manually rebuild them if there's upgrade and you need it.

Hold is exactly the thing you want to do -- it's designed exactly for this.

[ Parent | Reply to this comment ]

Posted by tong (69.156.xx.xx) on Mon 16 Jan 2006 at 16:14
[ Send Message | View Weblogs ]
 Hold is exactly the thing you want to do -- 

it's designed exactly for this.


On giving it a 2nd thought, it does make sence. thanks a lot. I'll do that.

tong

[ Parent | Reply to this comment ]

Posted by Anonymous (84.63.xx.xx) on Mon 16 Jan 2006 at 16:38
Yes, but how do you get informed, that an updated version did get released? I get no information at all, if I pin my self-built packages...

That's why I use the +somethingN modifier on my self-built packages.

Best regards,
Marc

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Mon 16 Jan 2006 at 18:21
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Using the packaging page upon the Debian server you can subscribe to new releases by email.

For example the apachetop package I maintain can be found here - with a form to the left to allow you to subscribe/unsubscribe to new releases.

Steve

[ Parent | Reply to this comment ]

Posted by Anonymous (84.63.xx.xx) on Tue 17 Jan 2006 at 08:00
Ah, yes, that would indeed be a solution. Unless...:
packages.debian.org is down at the moment due to performance issues.
Since a week at least *sigh* - missing it badly...

Best regards,
Marc

[ Parent | Reply to this comment ]

Posted by Anonymous (213.164.xx.xx) on Tue 17 Jan 2006 at 10:36
Yes it doesn't look good. They seem to have a lot of downtime lately.

Does anyone know the reason for the performance issues?
Are they planning on maying the infrastructure more redundant?

[ Parent | Reply to this comment ]

Posted by progfou (203.160.xx.xx) on Mon 16 Jan 2006 at 15:59
[ Send Message ]
You may "pin" some packages (yours or those from Debian) to tell your system how to consider upgrading depending on the package origin. Pin'ing doesn't prevent upgrading, but it allows to prioritize between different apt sources, or even enforce downgrade on specific conditions. See "man apt_preferences".

[ Parent | Reply to this comment ]

Posted by Anonymous (158.193.xx.xx) on Tue 17 Jan 2006 at 15:27
yes, preferences are the way. not hold, althought it does the job...

[ Parent | Reply to this comment ]

Posted by Anonymous (84.63.xx.xx) on Mon 16 Jan 2006 at 16:21
Not sure, this is the right way to do it, but it keeps my self-built packages from downgrading: I add "+" to my packages. I have a package called "gftp-gtk" installed, which I recompiled with ssl support: $> apt-cache policy gftp-gtk gftp-gtk: Installed: 2.0.18-11+ssl1 Candidate: 2.0.18-11+ssl1 Version table: *** 2.0.18-11+ssl1 0 100 /var/lib/dpkg/status 2.0.18-11 0 500 http://ftp.de.debian.org unstable/main Packages I want that package to stay in system as long as there is no new release in sid. It won't downgrade to 2.0.18-11, but it will upgrade to 2.0.18-12. Best regards, Marc

[ Parent | Reply to this comment ]

Posted by Anonymous (84.63.xx.xx) on Mon 16 Jan 2006 at 16:27
Arg, I'm sorry for that mess... first post, didn't know...

Not sure, this is the right way to do it, but it keeps my self-built packages from downgrading: I add "+" to my packages.

I have a package called "gftp-gtk" installed, which I recompiled with ssl support:
gftp-gtk:
  Installed: 2.0.18-11+ssl1
  Candidate: 2.0.18-11+ssl1
  Version table:
 *** 2.0.18-11+ssl1 0
        100 /var/lib/dpkg/status
     2.0.18-11 0
        500 http://ftp.de.debian.org unstable/main Packages
I want that package to stay in system as long as there is no new release in sid. It won't downgrade to 2.0.18-11, but it will upgrade to 2.0.18-12.

Best regards,
Marc

[ Parent | Reply to this comment ]

Posted by Anonymous (72.1.xx.xx) on Mon 16 Jan 2006 at 22:45
as part of a tool set, try debchanges from the devscripts package.

recently i used 'apt-src install balsa' to download the source for balsa 2.3.8-1 (and install its build-dependencies). then ran debchanges to increment the version number by .0.1 (which could in theory conflict with how the developer numbered their next release... caveat emptor):
/usr/src/balsa-2.3.8 $ debchange -v 2.3.8-1.0.1

this opens up the debian/changelog file and drops you into an almost-finished entry which you complete with the nature of the change.

after that (and an edit to the debian/rules file), 'apt-src build balsa' created the package balsa_2.3.8-1.0.1_i386.deb, which i installed. a new debian release will overwrite it, but until then it stays at the version i want.

[ Parent | Reply to this comment ]

Posted by undefined (192.91.xx.xx) on Mon 16 Jan 2006 at 23:57
[ Send Message ]
the parent is the first post that stated the "best" (maybe not "proper") way of doing it.

actually, it depends on the circumstances which way to best keep a self-built package.

i've never had a self-built package downgraded. you probably need to pin your default distro (stable, testing, unstable, experimental) a little below the automatic install level (990?).

the problem i initially encountered was that if i rebuilt a package, keeping the same version string as the original package (by not altering the changelog), then my version on the next "apt-get upgrade" would be reinstall using the official version (but could be due to my pinning of the official repositories).

if i only wanted to keep my package installed until the next version was released (ie i didn't want to wait for a security update or bug fix to propagate to testing), i just added "0.0.1" to the debian-specific version (ie "-1" -> "-1.0.1"). normally the versioning is <upstream version>-<debian package version>.<minor package revision>, so by adding another decimal and number after the "minor package revision" i've never had a conflict. ("minor package revisions" are not regularly used except for security updates in stable, but i prefer to be safe and not increment that number.)

if i want to manage my own package regardless of newer packages then i hold the package (echo <package> hold | dpkg --set-selections). i believe upon running "apt-get upgrade" it'll tell you which packages were not upgraded due to holds, so you'll notice when i newer version comes out (but not any subsequent newer versions).

i've found pinning to be too complex and error prone for single packages. i only pin whole distros (stable, testing, unstable) or repositories.

[ Parent | Reply to this comment ]

Posted by tong (67.71.xx.xx) on Sat 21 Jan 2006 at 22:43
[ Send Message | View Weblogs ]
you probably need to pin your default distro (stable, testing, unstable, experimental) a little below the automatic install level (990?)

That's exactly my problem. Thanks!

[ Parent | Reply to this comment ]

Posted by Anonymous (195.228.xx.xx) on Wed 18 Jan 2006 at 15:51
echo "package_name hold" | dpkg --set-selections

[ Parent | Reply to this comment ]

Posted by Anonymous (57.67.xx.xx) on Fri 20 Jan 2006 at 07:54
Hello *,

I have related questions (imho):

1/ my what's up if I want to better maintain a testing Debian for the most of my install and just want only some unstable pkg (e.g. for me binutils, gcc, ...), if I put the two 'trees' (testing/unstable) in my sources.list.

2/ and is there another method than dist-upgrade which would better allow me to select which pkg I would actualy updgrade now amoung the (sometime long) list of possible upgrade?

TIA,
Joel

[ Parent | Reply to this comment ]

Posted by undefined (68.93.xx.xx) on Sun 22 Jan 2006 at 06:50
[ Send Message ]
question 1:

$ man apt_preferences
...
$ cat /etc/apt/preferences
Explanation: debian testing
Package: *
Pin: release a=testing,o=Debian,l=Debian
Pin-Priority: 990

Explanation: unstable
Package: *
Pin: release a=unstable,o=Debian,l=Debian
Pin-Priority: -1

yeah, naming the man page for apt's preference file "apt_preferences" really surprised me the first time i learned of it because it's the only man page i've ever seen with an underscore where the underscore wasn't in a command/file name. (why isn't the man page simply called "preferences" like "hosts", "networks", "interfaces", or any other man page describing a file? if the man page for the preferences file is named "apt_preferences", why isn't apt.conf's man page named "apt_apt.conf"? :-P)

with the above setup my "apt-get update" updates the Packages files from both testing & unstable, apt-cache commands ("apt-cache search", "apt-cache show", "apt-cache policy") include both testing & unstable, but simple apt-get commands ("apt-get install <package>", "apt-get upgrade", "apt-get dist-upgrade") only use packages in testing.

but if i want to install a package from unstable (or the version in unstable) i do "apt-get install <package>/unstable". of course if the package has a lot of dependencies in unstable (which generate unfulfilled dependency errors with that command), i can either specify each individual package in the command, or just do "apt-get install -t unstable <package>" (which i rarely do as i'm a control freak and explicitly list each individual package so i can control exactly which packages get pulled in from unstable).

my pinnings will allow me to explicitly install packages from unstable, but never implicitly install or upgrade packages from unstable. iirc there is a value you can pin unstable with where once you upgrade to a package in unstable, you will continue to track newer versions of that package in unstable (as long as your installed version and the version in unstable is greater than the one in testing), but i can't remember the specific value.

for more information on "pinning" search google for "apt pinning" and you'll get plenty of hits.

question 2:

i always do a dist-upgrade just to see what packages are available, then do a install listing only the packages i explicitly want to upgrade (because sometimes a package introduces significant upstream changes that i am not prepared to deal with like udev, or i have significant customizations in my configuration and i don't want to take the time right then to merge the debian configuration file with my customized one like dhcp3). if a dist-upgrade only lists the packages i want, then i proceed with it (as i have apt configured to show me all affected packages and prompt me before proceeding; "apt-get --show-upgraded" or echo 'APT::Get::Show-Upgraded "yes";' >>/etc/apt/apt.conf).

[ Parent | Reply to this comment ]

Posted by Anonymous (57.67.xx.xx) on Thu 2 Feb 2006 at 10:57
Nice to learn more about apt's preference ;-)

Many tx for tips,
Joel

[ Parent | Reply to this comment ]

Posted by Anonymous (82.161.xx.xx) on Fri 20 Jan 2006 at 11:40
Don't know for sure, but i believe ther is a gentoo-like package called apt-source which can make sure your packages compiled from source don't get overwritten like you said, and get build again when there is an upgrade available.

however, google only shows hints about plain apt-get, so i could be wrong...

[ Parent | Reply to this comment ]

Posted by Anonymous (57.67.xx.xx) on Fri 20 Jan 2006 at 12:59
um, isn't it better 'apt-build'?

Hth,
Joel

[ Parent | Reply to this comment ]

Posted by undefined (68.93.xx.xx) on Sun 22 Jan 2006 at 06:44
[ Send Message ]
to list all the options of easily build a binary package from a source package (that i know of):

"apt-get source" is rather simplistic and primitive (and must be used with "apt-get build-dep" to be really useful), like dpkg is for binary packages.

"apt-src" is to source packages what apt is to binary packages and sounds most like what the original poster was describing (even automatically carrying forward patches the user applied to the previous version of a package). apt-src was created by joey hess in response to the real/perceived migration of debian users to gentoo and other automated source-based distributions (as compared to linux-from-scratch).

"pbuilder" is for building packages (including dependency resolution like "apt-get build-dep <package>; apt-get source <package>") within a chroot, which facilitates a user not having to install every build dependency (numerous *-dev packages) on their system (as all build-deps installed within the chroot are deleted immediately afterwards) and building packages for another distribution of debian (building packages for stable on testing/unstable).

"apt-build" appears to be for building packages customized for your processor (ie "gcc -march=athlon-xp" instead of the default "gcc -march=i386"), and may facilitate source code changes/patches, but appears to lack the advanced source management of apt-src (or at least it's not well advertised).

none of these deal with binary package management (keeping a self-built package installed despite newer official versions) that i know of, except for possibly installing a package ("dpkg -i <package>") immediately after building it.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

Which init system are you using in Debian?






( 1060 votes ~ 6 comments )