Date: Mon, 3 Dec 2012 10:20:17 -0500
From: Dubiousjim <lists+alpine-devel@jimpryor.net>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Some questions about apk-tools
Message-ID: <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>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121203154214.153cc8b0@vostro>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Mon, Dec 03, 2012 at 03:42:14PM +0200, Timo Teras wrote:

> > From quickly peeking at the source, it looks like:
> > 
> >     * `apk fix foo` and `apk fix -r foo` behave the same. Can I assume
> >       that it's always the current version that's re-installed, even
> > if an upgrade is available? And that if foo isn't currently installed,
> >       these commands do nothing?
> 
> Correct. This is a legacy thing, on previous versions (alpine 2.3 and
> earlier), the you had to specify -r or -u. That was kinda lame to
> most of the time need to write the extra -r, so now it is assumed if -u
> is not specified.
> 
> >     * `apk fix -u foo` won't reinstall foo, but will install an
> > upgrade for foo if one is available.
> 
> Correct.
> 
> > 
> >     * `apk fix -r -u foo` will install an upgrade for foo if one is
> >        available, else will reinstall the current version.
> 
> Correct.

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

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 _`.

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.

-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---