Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Wed, 5 Dec 2012 11:53:44 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Dubiousjim <lists+alpine-devel@jimpryor.net>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Some questions about apk-tools
Message-ID: <20121205115344.641973d3@vostro>
In-Reply-To: <20121203152017.GQ2390@vaio.jimpryor.net>
References: <20121128234406.GD2390@vaio.jimpryor.net>
	<20121129084044.29515fc1@vostro>
	<20121129124028.GE2390@vaio.jimpryor.net>
	<20121130154404.68b4de2a@vostro>
	<20121130151417.GI2390@vaio.jimpryor.net>
	<20121130153633.GJ2390@vaio.jimpryor.net>
	<20121203154214.153cc8b0@vostro>
	<20121203152017.GQ2390@vaio.jimpryor.net>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 3 Dec 2012 10:20:17 -0500 Dubiousjim
<lists+alpine-devel@jimpryor.net> wrote:

> Thanks Timo, except I was experimenting with these right now (before
> reading your email), to verify my hypotheses, and this is not the
> behavior I see.
> 
>     # apk version
>     Installed:                                Available:
>     linux-grsec-3.6.7-r0                    < 3.6.8-r1
>     cups-libs-1.6.1-r0                      < 1.6.1-r1
>     ghostscript-9.06-r2                     < 9.06-r3
>     imagemagick-6.8.0.4-r0                  < 6.8.0.7-r0
>     liblcms-1.19-r3                         < 1.19-r4
>     poppler-0.20.3-r1                       < 0.20.5-r0
>     poppler-gtk-0.20.3-r1                   < 0.20.5-r0
>     epdfview-0.1.8-r5                       < 0.1.8-r6
>     evince-2.32.0-r11                       < 2.32.0-r12
> 
> Ok, so given what we've said, I'd have expected
> `apk fix _` or `apk fix -r _` for one of the packages with an
> upgrade available to only install the current version, not the
> available upgrade. However:
> 
>     # apk fix cups-libs
>     (1/1) Upgrading cups-libs (1.6.1-r0 -> 1.6.1-r1)
>     Executing uclibc-utils-0.9.33.2-r14.trigger
>     OK: 831 MiB in 317 packages

This happens because the older version is no longer available in the
index. Thus it can't reinstall the same version. So it prefers to
intall the new version compared to doing nothing.

If you want to test the regular fix, you might take some cdrom image
and add it as one source - install package from it. Then add some
online repository and see if it has updated version. And then try
regular fix - it should reinstall the old version from cdrom.

> When the package is up-to-date, then `apk fix _` does indeed
> re-install:
> 
>     # apk fix cups-libs
>     (1/1) Re-installing cups-libs (1.6.1-r1)
>     Executing uclibc-utils-0.9.33.2-r14.trigger
>     OK: 831 MiB in 317 packages
> 
> But it seems like `apk fix _` is interpreted as `apk fix -u -r _`, not
> as just `apk fix -r _`.

Not exactly. It is more like: I want this package reinstalled. Please
reinstall the one currently installed, but if not available pick best
available option. (Which usually is the latest version).

> Verified that `apk fix -u _` is a noop if no upgrade is available:
> 
>     # apk fix -u cups-libs
>     OK: 831 MiB in 317 packages
> 
> I thought perhaps `apk fix -r _` might suppress any available
> upgrades, even if `apk fix _` didn't. Nope, it installed the upgrade
> and perhaps also assumed a `-d`:
> 
>     # apk fix -r evince
>     (1/4) Upgrading liblcms (1.19-r3 -> 1.19-r4)
>     (2/4) Upgrading poppler (0.20.3-r1 -> 0.20.5-r0)
>     (3/4) Upgrading poppler-gtk (0.20.3-r1 -> 0.20.5-r0)
>     (4/4) Upgrading evince (2.32.0-r11 -> 2.32.0-r12)
>     Executing busybox-1.20.2-r3.trigger
>     Executing uclibc-utils-0.9.33.2-r14.trigger
>     Executing glib-2.34.2-r0.trigger
>     Executing gtk+2.0-2.24.13-r2.trigger
>     Executing desktop-file-utils-0.20-r0.trigger
>     OK: 831 MiB in 317 packages
> 
> Hmm, so now I'm confused. It looks like the absence of a `-u` in
> `apk fix _` and `apk fix -r _` is not being honored. And maybe a `-d`
> is sometimes being tacitly assumed, too... unless the upgraded
> dependencies of evince were tagged with versions because they were
> auto-detected library dependencies. That wouldn't explain why the
> liblcms upgrade was applied, though.

I'm not sure about why this would happen. This could be a bug.



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---