26 Apr
2006
26 Apr
'06
10:48 a.m.
Hi Simone, On Tue, Apr 25, 2006 at 13:49:11 +0200, Simone Rota wrote: [...] > - Independently from the features we'd like to push, I'm in > favour of a rewrite; I suggest either plain C with libtar > or sh, with portability in mind. When talking about a rewrite in C, do you mean a full rewrite, or just pkgadd and symlinks? > I'm in the middle of a ANSI C pkgutils port, (pkginfo, pkgrm almost > done), my first impressions while working on the code is that > using sh would significantly speed up developement and make it > easier to add features in the future. Especially for pkgmk, sh/bash feels more natural. > - I'm a bit worried about the metadata proposal: > - Not sure if leaving free, per-repository attributes can make things > easier rather than produce confusion / lack of standards Well, it's not exactly per-repository data (at least not planned to be that way). There are basically two categories of attributes which are defined by a port: - required attributes, like name, version, release and files - optional attributes like depends All from the first two are included in binary packages (and in Pkgfiles). The optional ones can be added to the package db by changing the code of pkgadd, so it's not meant to be adjusted by the user. The thing which makes it different than the previous situation (users could always adjust pkgadd and recompile if they wanted) is that we explicitely consider that i.e. uCRUX might use a fork of pkgutils with different set of attributes, which means that tools depending on optional attributes might only work there but not on regular CRUX or the other way around. However, the ports are perfectly the same; it's just the content of the package database that differs. Finally, obviously the configurability is not coupled with attributes per se, so even if we want to implement the attributes idea, we don't have to expose its extensibility that much :-). Thanks for your comments, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch