Mail archive

Re: [alpine-devel] Alpine package browser

From: Natanael Copa <>
Date: Mon, 14 Feb 2011 14:31:54 +0000

On Mon, 14 Feb 2011 14:51:41 +0100
Carlo Landmeter <> wrote:

> On Mon, Feb 14, 2011 at 1:55 PM, Francesco <> wrote:
> > On Mon, 14 Feb 2011 07:47:37 -0500, Jeff Bilyk <>
> > wrote:
> >> Francesco,
> >>
> >> I'd agree that ideally we'd like this in ACF+lua since long-term,
> >> that keeps both tools (ACF and package browser) on a common
> >> platform.  It also would have the advantage, like you say, of
> >> having someone else who'd be able to then contribute to ACF, which
> >> is good for the long-term (and I'm sure Ted wouldn't mind having
> >> the help).  That being said, if those who are going to implement
> >> this solution (most likely nenolod and clandmeter iirc) prefer
> >> another language, like python, then I'm more inclined to say "lets
> >> get something out the door", especially something that imho would
> >> be a nice feature for the Alpine site.  If down the road it could
> >> be incorporated into ACF, that'd be great.  Just my 0.02$.
> >>
> >
> > From this point of view, sound reasonable.
> > The idea is good, and the alpine website does not use ACF.
> > I'm not referring, infact, to alpine website, but for our backend.
> > For public website, agree at 100%.
> This backend should be some sort of apk overlay to which we can add
> for instance maintainer and contributor. Because apk-tools is
> developed as a general package manager (not necessarily Alpine Linux)
> I think the apk index has some restrictions.

Not sure this is the way we want to go. I would really prefer not to
have same data in 2 different places. (as a comment in the apkbuild and
as a record in a db)

> It would be really nice
> if we can sort on maintainer/contributor and quickly check which
> packages belongs to you. Also allowing to flag packages as out of date
> and update maintainer/contributor would be a nice addition.

Yes. This is the problem we want to solve and I do have thought a
little of it over the time. Some points about the implementation:

* we don't want duplicate data if possible.
* some data currently only exists in aports (i.e buildtime deps) and
  some only in APKINDEX (i.e runtime deps which are generated during
* we do want keep the current APKINDEX as small as possible to
  keep apk update/add/del speedy. Thats why we dont have the entire
  filelists in there.

So, as i see it we have the following options:

* Parse both the current APKINDEX and parse the APKBUILDs
* add more fields in the .PKGINFO file and generate a second index/db
  build time (autobuilder can do this).

not sure how to do the need-update flag

> Of course
> there are many more features we can add, but for me this is a prio.

I am working on a APKBUILD parser in lua, but thats more for
calculating the build order and find what packages you need to rebuild
when you break ABI of a lib.

I'm also working on a lua binding to apk-tools. This is supposed to let
you sort packages by version and make apk-tools frontends (web and gtk

BTW, you talked about drupal plugin. Isn't drupal php and not python?
I kinda positive to drupal though.


Received on Mon Feb 14 2011 - 14:31:54 UTC