Subject: [alpine-devel] new aport utility: ap

From: Natanael Copa <[email-masked]>
Date: Mon, 13 Dec 2010 16:22:56 +0100

Hi,

I am working on a lua module called 'aports' and a utility to parse the
aports tree.

It is supposed to answer questions like:
* what aport provides package libfoo?
* what in what order should the following packages be built?
* what APKBUILDs depends on given package?

Note that apk packages and aports are 2 different things. For example,
the aport 'openssl' provides the following packages: openssl,
openssl-dev, openssl-doc, libcrypto1.0 and libssl1.0.

Some examples of current implemented functionallity:

usage: ap -d <DIR> SUBCOMMAND [options]

Subcommands are:
  builddirs
  recursdeps
  list
  revdep

Some examples:

To list all packages built in ~/aports/main:

  ap -d ~/aports/main list
...

List the build dirs in build order for libpq and openssl:

  $ ap -d ~/aports/main builddirs libpq openssl

Will give:
  /home/ncopa/aports/main/openssl
  /home/ncopa/aports/main/postgresql

List all packages that needs recompile when python is upgraded to new
ABI:

  ap -d ~/aports/main revdep python-dev python

List all aports in build order that needs recompile when python is
upgraded to new ABI:

  ap -d ~/aports/main revdep python-dev python \
    | xargs ap -d ~/aports/main builddirs

List all aports in build order:

  ap -d ~/aports/main list | xargs ap -d ~/aports/main builddirs

We need a config file (/etc/ap.conf?) where you can list your aports
dirs.

I am interested in feedback:

Is 'ap' a good name for this command?

Do we want 'ap <subcommand>' or ap-subcommand as a symlink? or separate
file?

Are the 'builddirs' 'revdeps' and 'recursdeps' good names for
subcommands?

Maybe 'builddirs' should be renamed to 'where-is'?

Maybe 'revdeps' should be renamed to 'who-needs'?

Maybe 'recursdeps should be renamed to 'all-deps'?

The tool is in abuild.git if someone wants to try it.

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: "Matt Smith" <[email-masked]>
Date: Mon, 13 Dec 2010 13:26:54 -0600 (CST)

I'm wondering if we should have an extra sub-command that would allow one to search all APKBUILDs in their aports for their name or another contributor/maintainer's name.  This would allow contributors to keep track of which package(s) they're involved in.

I'd actually just made a one-liner shell command for this prior to checking my e-mail:
grep -rHi "Matt Smith" ~/aports/ | grep -E 'aports/(testing|main)/[^/]+/APKBUILD' | awk -F '/' '{print $5 "/" $6}' | sort -u

On Monday, December 13, 2010 9:22am, "Natanael Copa" <[email-masked]> said:
...
...

I think having a config file is a great idea.

I also have a few ideas that I'd like to see what you think about:
- Rename 'ap' to 'aports'
- Make 'ap' / 'aports' similar to 'apk' in regards to sub-commands; include abuild, abump, newapkbuild, etc. as sub-commands to 'ap' / 'aports' (e.g.: aports build -r, aports newapkabuild newpackage)
- Rename /etc/abuild.conf to /etc/aports.conf and add variable(s) for 'ap' / 'aports' pointing to the local aports directory(s)

- Matt

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 14 Dec 2010 08:37:06 +0100

On Mon, 13 Dec 2010 13:26:54 -0600 (CST)
"Matt Smith" <[email-masked]> wrote:

> I'm wondering if we should have an extra sub-command that would allow
> one to search all APKBUILDs in their aports for their name or another
> contributor/maintainer's name.  This would allow contributors to keep
> track of which package(s) they're involved in.
> 
> I'd actually just made a one-liner shell command for this prior to
> checking my e-mail: grep -rHi "Matt Smith" ~/aports/ | grep -E
> 'aports/(testing|main)/[^/]+/APKBUILD' | awk -F '/' '{print $5 "/"
> $6}' | sort -u

Right. The current lua script implementation is not really good for
this but could be done ofcourse. Currently the script will source each
APKBUILD and echo $pkgname $pkgver $source etc so variable expansion
works properly. In other words, the comments are currently ignored.

But yes. We need a tool for this.

> On Monday, December 13, 2010 9:22am, "Natanael Copa"
> <[email-masked]> said: ...
> > Do we want 'ap <subcommand>' or ap-subcommand as a symlink? or
> > separate file?
> ...
> 

Maybe /etc/aports/aports.conf

and move /etc/abuild.conf to /etc/aports/abuild.conf ?

> - Rename 'ap' to 'aports'

Will that not cause confusion? When you talk about aports, do you talk
about the aports tool or the ported applications, buildscripts?

> - Make 'ap' / 'aports' similar to 'apk' in regards to sub-commands;
> include abuild, abump, newapkbuild, etc. as sub-commands to 'ap' /
> 'aports' (e.g.: aports build -r, aports newapkabuild newpackage)

I was thinking of simplifying the abuild script, remove all the code
doing dependencies, recursive building etc, and let 'aports' utility do
that, but keep the shell script to do simple building. Like gentoo has
'emerge' and 'ebuild'

> - Rename /etc/abuild.conf to /etc/aports.conf and add variable(s) for
> 'ap' / 'aports' pointing to the local aports directory(s)

Hmm... We dont want 2 different tools? One that does the actuall
building and one that searches/analyzes the aports tree.

In any case i think we might want the aports.conf be
readable from shell scripts.

> - Matt

Thanks for the feedback!

-nc

---

---

From: "Matt Smith" <[email-masked]>
Date: Tue, 14 Dec 2010 14:32:31 -0600 (CST)

> and move /etc/abuild.conf to /etc/aports/abuild.conf ?

Yeah, that sounds good.

> about the aports tool or the ported applications, buildscripts?

Hm.. true, but I'm not sure 'ap' is the best name either.  Depending
on what all it's intended to do, what about naming it 'aportinfo' or
some variation of that? Maybe even ainfo.

> that, but keep the shell script to do simple building. Like gentoo has

I read the conversation in #alpine-devel regarding this, and it makes
sense... I'm just not sure what to call the individual tools.

Perhaps 2-3 tools:
- abuild / apkbuild / apbuild: build one aport/apk
- abuild / arec / arbuild: recursive building, etc
- ainfo: aports information

> building and one that searches/analyzes the aports tree.

At first I wanted a combined tool, but I don't mind either way.

> readable from shell scripts.

Sounds good.

> -nc

No problem.  Let me know what you think!

- Matt

---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 15 Dec 2010 14:31:27 +0100

> some variation of that? Maybe even ainfo.

agree. 'ap' is not really good either.

> - ainfo: aports information

I need to think more about this. I'll try to focus on the backend libs
for now.

-nc

---