[pacman-dev] repose and contributing generic PKGINFO/database parsers
Hey, so following up with discussions that happened yesterday on #archlinux. So, for context, I have a project for building Arch Linux repositories in an automated way: https://github.com/vodik/repose Some of you guys are aware of the project, but for those that aren't, its an alternative for the repo-add and repo-remove utilities. It attempts to intelligently build an optimal repository from a pool of packages and automatically handles incremental rebuilds in an automated way. For the most part, its faster than repo-add and fits better with makepkg and PKGDEST. As part of the project I've had to write my own utilities for processing tarballs and parsers and for the pacman database desc/depends/files entries and .PKGINFO file. I wanted to use reuse the official libalpm utilities, but I found them too tightly coupled into how libalpm expects to be used and the layout of the package structure. I initially copied out the internal parsers and modified them, but they've since been replaced with ragel-generated standalone parsers. They have their own test coverage and do run quite a bit faster. I'm curious if there's any interest in accepting some of this work and on what kind of terms? As patches to libalpm for my decouple parsers? Is ragel okay? Or if maybe its something that's best as a standalone library?
On 31/10/16 08:39, Simon Gomizelj wrote:
Hey, so following up with discussions that happened yesterday on #archlinux.
<snip> So many issues to respond to in one email! 1) Are we interested in a repo-add replacement? Yes - I was looking at being able to add source package information to repositories (which could server as a replacement to ABS) and found repo-add to limited. We also have a package information parser in repo-add and another one in libalpm, so there is unneeded duplication there. Adding source package information also brings up the issue we currently have with .db and .files repos containing overlapping information. Where does source package info go? But this is a separate discussion. 2) Are we interested in more general purpose parsers? The libaplm parsers were not suitable for your purpose for some reason. We would need more information of what would need changed to consider whether to include it. But, in general, making libalpm more useful for other projects is a something we consider. 3) Using ragel to generate the parsers. This interests me much less. I agree that we could gain some speed here, but that really is not an issue... "pacman -Sii glibc" parses every repo in my pacman.conf and takes in total less than 0.3 seconds on my system. That is not much room for gain for the addition of another build time dependency and the need for contributors to learn ragel syntax. Allan
participants (2)
-
Allan McRae
-
Simon Gomizelj