Date: Sun, 1 Dec 2013 12:45:54 -0500
From: Dubiousjim <dubiousjim@gmail.com>
To: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] a few abuild oddities
Message-ID: <20131201174554.GB29236@zen>
Mail-Followup-To: alpine-devel@lists.alpinelinux.org
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.22 (2013-10-16)

I'm puzzled about a few things with abuild.

First, a long-standing issue has been that if you do:

   abuild -r -i pkg1 -i pkg2

then the .makedepends-foo package doesn't get deleted.

Second, I don't understand how abuild is acquiring sufficient
permissions to do what it seems to be doing in these cases.

My user belongs to the "abuild" group, but normally isn't able to even
acquire a lock on the apk database, much less add or del packages,
without raising privileges via sudo or su. Also, my /etc/apk/world file
lists as:

-rw-r--r--    1 root     root           885 Dec  1 11:58 /etc/apk/world

However, I can be sure that sudo hasn't cached any privileges (sudo -k)
and go into an aports directory and type `abuild -r -i pkg1` (supplying
an appropriate package name), and then WITHOUT EVER ASKING FOR A
PASSWORD, abuild will:

* download and install the necessary dependencies: I assume it shouldn't
  be able to do this without privileges, although possibly the packages
  are getting installed in an overlay or some-such ... I know that
  didn't use to be the case, but I haven't kept close tabs on how the
  code has developed over the past year or so. Even if the packages
  weren't really getting installed to /, where the user running abuild
  lacks sufficient privileges, still how can abuild update
  /etc/apk/world? which one can see it does because the .makedepends-foo
  virtual package never gets deleted (see first issue above)

* if the build completes successfully, then install the relevant local
  package, again which it shouldn't be able to do without prompting for
  a password

Perhaps the issue here isn't with abuild, but rather with one or the
other of fakeroot and sudo?

Third question: In my local aports clone, I have some separate branches
for my local additions and tweaks. Some of that stuff goes into
$APORTS/local, when there is no corresponding package already in the
tree. But other stuff goes into $APORTS/main and $APORTS/testing; this
helps me keep track of when the master branch and my local branches have
diverged, and makes it easier to merge them. I assume other Alpine
developers and hackers have a similar workflow.

Now, suppose I happen to have built a local copy of foo-1.2-3.apk on my
machine. Then the official repositories get foo-1.2-4.apk, and suppose I
happen to install that. Then when I get around to housekeeping my
machine properly, I'll sync my local aports branch with master, and
build my own version of the new foo-1.2-4, with my custom build
instructions. My habit is to just name this foo-1.2-4, as well, since we
don't have any conventions for handling additional release suffixes. And
I don't want to name my custom version foo-1.2-5, since that may also be
released in the official repositories later and be rather different. So
I just name my custom version foo-1.2-4 as well, and make sure that my
local package folder comes before the official repositories in
/etc/apk/repositories. This works fine.

The only tricky thing is, how now to tell Alpine that I want to install
the new, custom-build package in place of the already-installed package
with the same version and release from the official repositories. There
are at least two ways one can do this:

   sudo apk add $REPODEST/main/x86/foo-1.2-4.apk

or:

   # inside $APORTS/main/foo/
   abuild -r -i foo

I think the latter works even if the package has already been built and
locally indexed. (Plus as I pointed out above, it seems to avoid the
nuisance of supplying a su/sudo password. :-)) But in either of these
cases, I then tend to:

   sudo vim /etc/apk/world

find the "foo><123456789..." line, and then either delete it (if foo is
already a dependency of another package in world) or modify it to just
read "foo". This is the only way to ensure that future updates to foo in
the official repositories show up when I say "apk upgrade --sim" or
such.

What I'm leading up to is that it'd be nice if there was some easier way
to get the newly built local package to be preferred to the
already-installed package from the official repositories. Then I
wouldn't have to manually poke around in /etc/apk/world.
As I said, the directory that the newly-built package resides in is getting indexed
properly by abuild, and it comes before the official repositories in my
/etc/apk/repositories. But neither of these:

  apk fix -u foo

nor:

  apk fix -r foo

will use the newly-built package, not even if I do "apk update" first.

I'm not sure if:

  apk upgrade -a

will use the newly-built package. Even if it does, though, this isn't
super-helpful to me because I'm often trying to juggle these package
replacements when I've got a queue of not-yet-applied (and
not-yet-ready-to-apply) upgrades.

Any thoughts/ideas/suggestions?

-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---