Subject: [alpine-devel] Alpine package browser

From: Carlo Landmeter <[email-masked]>
Date: Mon, 14 Feb 2011 10:49:24 +0100

I have been talking on IRC about setting up a package browser for our
APK repo's.
Nenolod has agreed to write an apkindex parser in python (he had some
questions regarding APKINDEX format), and I would write a module for
Drupal which will act as interface.

As an starting point I would like to refer to Archlinux package
browser: http://www.archlinux.org/packages

So to get discussion started about this project, I would like to get
some opinions about the above concept.

Some topics to discus

* Python APKINDEX parser
* APKINDEX format (possible to get additional information like
maintainer/contributor...)
* Parser linking to git/buildbot for updates
* APK SQL database schema
* Drupal as Package browser (or do we prefer ACF)
* APK browser features compared Arch/others
* Additional features/information like git rss viewer
* ....

-carlo

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

---

From: Francesco Colista <[email-masked]>
Date: Mon, 14 Feb 2011 10:58:49 +0100

> * Additional features/information like git rss viewer

I agree with all this point.
I think (IMHO) is better to use the ACF + Lua.
It's the standard alpine framework, is fast, and Ted will appreciate
some helps :)

My two cents.
-- 
:: Francesco ::
Jabber: [email-masked]
E-Mail: [email-masked]
GnuPG: FE9DDD5F

---

---

From: Carlo Landmeter <[email-masked]>
Date: Mon, 14 Feb 2011 12:27:47 +0100

> It's the standard alpine framework, is fast, and Ted will appreciate

If Ted is up to this task to develop this in ACF + Lua then i would endorse it.
This means all new functions/features will also be developed, do we
want that or should we use existing solutions and focus on development
of Alpine Linux?

---

---

From: Francesco <[email-masked]>
Date: Mon, 14 Feb 2011 13:14:27 +0100

> want that or should we use existing solutions and focus on development

Dunno if Ted has time to develop this feature, we should ask to him.
I'm just wondering that we should use the actual existing framework and
add features to it.
If someone is available to write lua code for ACF and helps Ted, this
is appreciated.
But, obiouvsly, this is IMHO.

---

---

From: Jeff Bilyk <[email-masked]>
Date: Mon, 14 Feb 2011 07:47:37 -0500

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$.

Jeff

-- 
Jeff

---

---

From: Francesco <[email-masked]>
Date: Mon, 14 Feb 2011 13:52:54 +0100

> that'd be great.  Just my 0.02$.

F

---

---

From: Francesco <[email-masked]>
Date: Mon, 14 Feb 2011 13:55:25 +0100

>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%.

---

---

From: Carlo Landmeter <[email-masked]>
Date: Mon, 14 Feb 2011 14:51:41 +0100

> 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. 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. Of course
there are many more features we can add, but for me this is a prio.

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 14 Feb 2011 14:31:54 +0000

On Mon, 14 Feb 2011 14:51:41 +0100
Carlo Landmeter <[email-masked]> wrote:

> >> 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$.
> >>
> >
> 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
> 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
  build)
* 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

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
etc).

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

-nc

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Mon, 14 Feb 2011 16:48:39 -0600

> I kinda positive to drupal though.

Drupal is PHP, and ugly PHP at that.  I played around with some plugins
once.  It wasn't pretty.  Anyway, I'm not sure what Drupal would add to your
project here.

Jeremy Thomerson

---

From: Ted Trask <[email-masked]>
Date: Mon, 14 Feb 2011 08:29:04 -0800 (PST)

Ted is not up to this task right now. :) Go with the existing solution that you 
prefer for alpinelinux.org.

Ted

----- Original Message ----
From: Carlo Landmeter <[email-masked]>
To: [email-masked]
Cc: Alpine-devel <[email-masked]>
Sent: Mon, February 14, 2011 6:27:47 AM
Subject: Re: [alpine-devel] Alpine package browser

---

____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

---

---

From: Nathan Angelacos <[email-masked]>
Date: Tue, 15 Feb 2011 07:02:51 -0800

Back to the issue at hand...

> * Python APKINDEX parser

I *do not* want to start a language war here.  But ncopa's leaning 
toward Lua, and ACF is Lua; Is there a specific reason for python?

> * Additional features/information like git rss viewer

I like the concept.  Do we start with something that looks like
http://www.archlinux.org/packages, and go from there?

What's there looks very doable with ACF, even with my skills; but I 
don't want to slow anyone from doing something faster.

---

---

From: Carlo Landmeter <[email-masked]>
Date: Tue, 15 Feb 2011 20:23:17 +0100

On Tue, Feb 15, 2011 at 4:02 PM, Nathan Angelacos <[email-masked]> wrote:
> I *do not* want to start a language war here.  But ncopa's leaning toward
> Lua, and ACF is Lua; Is there a specific reason for python?
>
> What's there looks very doable with ACF, even with my skills; but I don't
> want to slow anyone from doing something faster.
>

I have prepared the first part of my drupal module to parse the
apkindex.tar.gz. Drupal's node system is since version 7 very
flexible. In drupal, content is based on a node which belongs to a
particular content type. I will create a specific content type "apk"
which will have all the fields i can parse from apkindex. Then
depending on the repo we can create Taxonomy terms in drupal and link
it so we get a proper structure. We can of course extent the content
type to have more fields like maintainer/contributor or any other
field which is interesting to be browsed. To keep everything
up-to-date I will add an update function which hooks up to drupal cron
so its automatically updated.
When I have something to show I will create a new repo on git.a.o and
push the changes.

---