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: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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" <ncopa@alpinelinux.org> said:
...
> 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?
...
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
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 13 Dec 2010 13:26:54 -0600 (CST)
"Matt Smith" <mcs@darkregion.net> 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"> <ncopa@alpinelinux.org> said: ...> > 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?> ...> > I think having a config file is a great idea.
Maybe /etc/aports/aports.conf
and move /etc/abuild.conf to /etc/aports/abuild.conf ?
> I also have a few ideas that I'd like to see what you think about:> - 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
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Tuesday, December 14, 2010 1:37am, "Natanael Copa" <ncopa@alpinelinux.org> said:
> On Mon, 13 Dec 2010 13:26:54 -0600 (CST)> "Matt Smith" <mcs@darkregion.net> wrote:> >> I think having a config file is a great idea.> > Maybe /etc/aports/aports.conf> > and move /etc/abuild.conf to /etc/aports/abuild.conf ?
Yeah, that sounds good.
>> I also have a few ideas that I'd like to see what you think about:>> - 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?
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.
>> - 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'
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
>> - 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.
At first I wanted a combined tool, but I don't mind either way.
> In any case i think we might want the aports.conf be> readable from shell scripts.
Sounds good.
> Thanks for the feedback!> > -nc
No problem. Let me know what you think!
- Matt
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Tue, 2010-12-14 at 14:32 -0600, Matt Smith wrote:
> On Tuesday, December 14, 2010 1:37am, "Natanael Copa" <ncopa@alpinelinux.org> said:> > On Mon, 13 Dec 2010 13:26:54 -0600 (CST)> > "Matt Smith" <mcs@darkregion.net> wrote:> > > >> I think having a config file is a great idea.> > > > Maybe /etc/aports/aports.conf> > > > and move /etc/abuild.conf to /etc/aports/abuild.conf ?> > Yeah, that sounds good.> > >> I also have a few ideas that I'd like to see what you think about:> >> - 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?> > 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.
agree. 'ap' is not really good either.
> >> - 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'> > 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
I need to think more about this. I'll try to focus on the backend libs
for now.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---