what next for the pkg_install rewrite
bapt at freebsd.org
Thu Sep 2 09:52:07 UTC 2010
On Thu, Sep 02, 2010 at 12:34:58AM -0700, David Forsythe wrote:
> Eh, why didn't this thread spring up before summer of code got under
> way (or during the many weeks it was running)?
I was expecting for your reply :)
Sorry I didn't launch this thread before that because I didn't get enough spare
time before summer, nor during it.
> Concerning the database situation, sqlite would be cool. If we can
> ship the sqlite code either with libpkg or with the pkg_install tools,
> it's a win (I don't read licenses, someone will have to tell me if we
> can do that). Realistically, if this is doable, then there can be no
> opposition because the pkg_install tools as they are now create their
> own "database", so nothing is changing. Plus we'll get free
> concurrency, which everybody wants. If I can get an okay on this,
> I'll start reworking libpkg to handle it.
sqlite if we goes on is BSD-like licensed so it should ne be a problem, it is
designed to be embeded (one .h and .c to compile) no need to import the full
sqlite sources. (see www.fossil-scm.org from the author of sqlite).
> The manifest format really does need to change. We should go with
> JSON and either write our own specialized parser/writer or go with
> something like yajl. Writing a parser and a writer that plug into my
> libpkg will give you conversion tools (both forwards and backwards)
> for free and adding properties and changing formats isn't really a big
> deal because I store package information in a plist(5) (from OS X)
> like structure. Bringing a fat library into base just for manifest
> parsing will meet with resistance, so if you guys can find some really
> small json lib (I'm talking 1 or 2 files) that's license compatible,
> I'll happily suck it into libpkg.
That would be great, the json lib I use for testing purpose cjson
(http://sourceforge.net/projects/cjson/) which is really simple to use, BSD
license and can be embeded. I have writen a pkg_register which is a quick and
dirty version of pkg_add -O just to be a dropin replacement of PKG_CMD for ports
to register new package with the new manifest (without the need of patching
> The lua stuff is way too far off in dream land for my taste...
I think the only interest of lua in pkg_install would be to allow hooks written
in lua but this is not very important in the state we are).
So let's forget lua for the moment :)
> The things that you guys want to drop from plists are things gcooper
> has been wanting to get rid of and replace for a while, and libarchive
> restoring group/mode/owner perms has been the plan for a while now I
> believe (I actually just ignore this stuff in libpkg).
> Separating ports and packages is silly, because they need to coexist.
> Like gcooper pointed out, ports should be using the pkg tools to build
> and install packages.
Agree with that
> The repository format is something that you guys didn't really touch
> on that I think could use some fixing, but I'll wait to see where this
> all goes and maybe throw some ideas on a wiki page later on.
I expect for your ideas on the wiki page.
> In the mean time, I'll keep building libpkg too work with the pkg
> system in its current state.
How hard would it be to add support for the new manifest on you libpkg which is
really great by the way :)
How hard would it be to allow other developers to work with you on libpkg?
separate the tasks etc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20100902/6d3b02e7/attachment.pgp
More information about the freebsd-ports