On Sun, Aug 10, 2008 at 09:59:32AM +0200, Vincent Fourmond wrote: > > Marcin Owsiany wrote: > > | - making local changes to the official version. In this case, the most > > | reliable way is to make the version string sort as older than the > > | official one (using the "tilde" feature of dpkg) and force > > | installation of such package using pinning. (The other strategy: > > | trying to invent a version string newer than the current one, but > > | older than the next one is difficult to do reliably.) > > In that case, a solution that comes to my mind is to use the Forbid > feature of aptitude: you install the locally-modified version and forbid > the version currently in stable. This way, aptitude won't install it, > but it will upgrade to a later version if there is one.
I must admit that I did not know this particular feature of aptitude. However after having a look at the documentation, it does not seem to be the right tool in the case which is most interesting for me, that is automated package management on distributed hosts. It seems like you need to at least run a command on each host for each package/version combination that you do not like. Does not sound really scalable, especially combined with the fact that "only one version can be forbidden at once." Moreover, even though I find aptitude indispensable on a desktop, I refrain from using it for automation due to things like #445035 or #445034. I've started coding now, but for several reasons I decided to implement it in python (using python-apt). If it works, then it can always be treated as a prototype and reimplemented as an apt-cache subcommand. -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
