From: "V.Krishn" <vkrishn4@gmail.com>
Reply-To: vkrishn4@gmail.com
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Questions about apk CMD -U
Date: Tue, 30 Oct 2012 13:25:03 +0530
User-Agent: KMail/1.13.7 (Linux/3.3.7-64; KDE/4.7.4; x86_64; ; )
References: <20121029181737.GB16841@vaio.jimpryor.net> <20121029225747.GD16841@vaio.jimpryor.net> <20121030080626.778185d0@vostro>
In-Reply-To: <20121030080626.778185d0@vostro>
Precedence: list
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201210301325.04001.vkrishn4@gmail.com>

On Tuesday, October 30, 2012 11:36:26 AM Timo Teras wrote:
> On Mon, 29 Oct 2012 18:57:47 -0400 Dubiousjim
> 
> <lists+alpine-devel@jimpryor.net> wrote:
> > If one does have multiple repositories listed in one's
> > /etc/apk/repositories or /etc/apk/repository.d/*.list files, and
> > several of those repos contain foo-1.23-r0.apk, but the package
> > binaries differ, is there any system to which repository will be used?
> 
> Yes - but it is not trivial and depends on the action executed.
> 
> If everything looks identical - package version, dependencies, etc.
> Then in practice apk prefers the repository listed first. In case of
> *.list files, it is currently the physical order in which those files
> are read. And that can be hard to predict.
> 
> > Here's why I ask. I'm still in the process of shifting myself into
> > Alpine. From past experiences with Arch and FreeBSD, I've noticed the
> > following pattern. I tend to accumulate a bunch of packages which are
> > in the official repositories, but for which I want to customize the
> > build. The way I've settled into doing this is to have a personal git
> > branch in my aports repo. Then when the official APKBUILDs get
> > updated, I'll see the changes when I try to merge the master branch
> > with my personal branch.
> > 
> > But what version should I give my custom packages? Ideally, I'd want
> > to be able to insert any number of my own revisions in between the
> > official foo-1.23-r0 and foo-1.23-r1. I'd also want to be able to
> > insert any number of my own revisions before the official
> > foo-1.23-r0, if I end up building that before it appears in the
> > official repositories. If there's some way to insert my packages into
> > gaps in the existing versioning space, terrific.
> > 
> > If not, then I'm guessing the best thing to do is to name my custom
> > package foo-1.23-r0 also. It will be a different binary than the
> > official foo-1.23-r0. But if I arranged for my local package
> > repositories to be searched first, then I'd be sure to always get my
> > home-built packages, unless the official binary gets ahead of me
> > version-wise. This is why I'm asking which repos in one's
> > /etc/apk/repo** files have priority over the others.
> > 
> > I'm sure others have come up with schemes to deal with this. I'd
> > welcome any feedback about what tends to work best.
> 
> If you want to make sure you use always your custom package - add your
> own repository with @ownrepo tag, and use "apk add mypackage@ownrepo"
> to add them. The repository pinning overrides even version matching
> and upgrades - if necessari it will downgrade packages to make it work.
> 
> Alternatively you should modify the version. If the -rN level does not
> matter. Then you could add _p1 suffix before it - e.g. foo-1.2.3_p1-r0.
> Though, there are few packages that use the _pN suffix on their main
> versions (you can still suffix with second _pN too).
> 
> Perhaps we should fix the -rN field to allow decimal point for
> "customized" builds or similar, like '-r1.1'. Any opinions on this?
> Or any other ideas?

How does _pN suffix get applied?
I mean , can it be any _<text>N? 
if not then '-r1.1' may not be very helpful, coz package name should indentify 
the packager in someway.

-- 
Regards.
V.Krishn

> 
> - Timo
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---