mbox series

[RFC,WIP,0/5] adding extended package data

Message ID 20220206183041.104788-1-andrew.gregory.8@gmail.com
Headers show
Series adding extended package data | expand

Message

Andrew Gregory Feb. 6, 2022, 6:30 p.m. UTC 
ALPM is currently parsing several fields that are not particularly relevant to
managing package installation (e.g. pkgbase, pkgtype, makedepends,
checkdepends).  pkgtype in particular is not even exposed in any way through
the API, it has to be included in the parser with a "not actually used"
comment.  This patchset adds an extended data field to packages that can be
used by packagers or package-building infrastructure to store arbitrary package
data in a way that doesn't require altering alpm for every field and allows the
data to actually be retrieved via alpm (though not as easily as first-class
fields).

Andrew Gregory (5):
  query: only strip leading local/ for db packages
  query: allow querying extra info for package files
  add data field for arbitrary package data
  query: print extended data when extra info is requested
  makepkg: store package type in extended data

 lib/libalpm/alpm.h       |  7 +++++++
 lib/libalpm/be_local.c   | 25 +++++++++++++++++++++++++
 lib/libalpm/be_package.c |  6 ++++++
 lib/libalpm/be_sync.c    | 16 ++++++++++++++++
 lib/libalpm/package.c    | 17 +++++++++++++++++
 lib/libalpm/package.h    |  6 ++++++
 scripts/makepkg.sh.in    |  2 +-
 src/pacman/package.c     | 13 +++++++++++++
 src/pacman/query.c       | 16 ++++++----------
 9 files changed, 97 insertions(+), 11 deletions(-)

Comments

Allan McRae March 6, 2022, 7:17 a.m. UTC | #1 
On 7/2/22 04:30, Andrew Gregory wrote:
> ALPM is currently parsing several fields that are not particularly relevant to
> managing package installation (e.g. pkgbase, pkgtype, makedepends,
> checkdepends).  pkgtype in particular is not even exposed in any way through
> the API, it has to be included in the parser with a "not actually used"
> comment.  This patchset adds an extended data field to packages that can be
> used by packagers or package-building infrastructure to store arbitrary package
> data in a way that doesn't require altering alpm for every field and allows the
> data to actually be retrieved via alpm (though not as easily as first-class
> fields).
> 
> Andrew Gregory (5):
>    query: only strip leading local/ for db packages
>    query: allow querying extra info for package files
>    add data field for arbitrary package data
>    query: print extended data when extra info is requested
>    makepkg: store package type in extended data

This looks a good idea to me.  Nothing stood out on a quick skim of the 
patches.

I assume patches 1 and 2 could be committed now?
Andrew Gregory March 7, 2022, 3:44 a.m. UTC | #2 
On 03/06/22 at 05:17pm, Allan McRae wrote:
> On 7/2/22 04:30, Andrew Gregory wrote:
> > ALPM is currently parsing several fields that are not particularly relevant to
> > managing package installation (e.g. pkgbase, pkgtype, makedepends,
> > checkdepends).  pkgtype in particular is not even exposed in any way through
> > the API, it has to be included in the parser with a "not actually used"
> > comment.  This patchset adds an extended data field to packages that can be
> > used by packagers or package-building infrastructure to store arbitrary package
> > data in a way that doesn't require altering alpm for every field and allows the
> > data to actually be retrieved via alpm (though not as easily as first-class
> > fields).
> > 
> > Andrew Gregory (5):
> >    query: only strip leading local/ for db packages
> >    query: allow querying extra info for package files
> >    add data field for arbitrary package data
> >    query: print extended data when extra info is requested
> >    makepkg: store package type in extended data
> 
> This looks a good idea to me.  Nothing stood out on a quick skim of the
> patches.

One bikeshed question: I used what I felt was the most obvious storage for each
of our formats, should they be unified?  I.e. should .PKGINFO use something
like "data = name value" instead of "data-name = value" to more closely match
desc files?

> I assume patches 1 and 2 could be committed now?

Yes.
Allan McRae March 7, 2022, 5:15 a.m. UTC | #3 
On 7/3/22 13:44, Andrew Gregory wrote:
> On 03/06/22 at 05:17pm, Allan McRae wrote:
>> On 7/2/22 04:30, Andrew Gregory wrote:
>>> ALPM is currently parsing several fields that are not particularly relevant to
>>> managing package installation (e.g. pkgbase, pkgtype, makedepends,
>>> checkdepends).  pkgtype in particular is not even exposed in any way through
>>> the API, it has to be included in the parser with a "not actually used"
>>> comment.  This patchset adds an extended data field to packages that can be
>>> used by packagers or package-building infrastructure to store arbitrary package
>>> data in a way that doesn't require altering alpm for every field and allows the
>>> data to actually be retrieved via alpm (though not as easily as first-class
>>> fields).
>>>
>>> Andrew Gregory (5):
>>>     query: only strip leading local/ for db packages
>>>     query: allow querying extra info for package files
>>>     add data field for arbitrary package data
>>>     query: print extended data when extra info is requested
>>>     makepkg: store package type in extended data
>>
>> This looks a good idea to me.  Nothing stood out on a quick skim of the
>> patches.
> 
> One bikeshed question: I used what I felt was the most obvious storage for each
> of our formats, should they be unified?  I.e. should .PKGINFO use something
> like "data = name value" instead of "data-name = value" to more closely match
> desc files?
> 
I'd prefer .PKGINFO as "data = name value".  And we can put a 
restriction that data field names have no whitespace.


>> I assume patches 1 and 2 could be committed now?
> 
> Yes.
> .