On Mon, 14 Feb 2011 14:51:41 +0100
Carlo Landmeter <clandmeter_at_gmail.com> wrote:
> On Mon, Feb 14, 2011 at 1:55 PM, Francesco <francesco_at_bsod.eu> wrote:
> > On Mon, 14 Feb 2011 07:47:37 -0500, Jeff Bilyk <jbilyk_at_gmail.com>
> > 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