Alex Griffin (2016-05-08 17:43 +0300) wrote: > On Sun, May 8, 2016, at 03:13 AM, Alex Kost wrote: >> I suggest (gnu packages textutils); I see 'utf8proc' is placed there. I >> think this is also a suitable module for 'libunistring' (currently it is >> placed in its own file), but it's a separate question. > > Okay. I had assumed textutils was for command line utilities, but if > that's where utf8proc goes then utfcpp seems to fit there too.
Note that I'm not an expert in finding the most suitable module. I often have the same problem when I make a package. But in this case, I think (gnu packages textutils) is OK. >> Not a big thing but we indent '#:use-module' by 2 spaces. Out of >> curiosity: what editor do you use? > > I use Emacs, the bad indenting is just from moving the package out of > another file with incorrect indentation (finance.scm). Ah, OK, it happens, we have many not perfect indentations here and there, sorry :-) >> I don't know whether we have an idiomatic way to convert "2.3.4" into >> "2_3_4", but I would just use a tarball from github: > > The project was just migrated to GitHub and hasn't had a new release > since then, so I'm using the sourceforge zip file because that's what > other projects have downloaded and used. Also I try to avoid the > automatically-generated GitHub archives because they're prone to change > hashes (although I see I forgot about that in the ledger package.) This is doubtful; do you have any proof? We use a lot of tarballs from github and AFAIK we have never seen any hash changes. These tarballs are just tagged snapshots of the git repos, so the only way I see they can be changed is when the upstream pushes a tag, then deletes it, and recreates it (probably after some commit history rewriting and force pushing). And I don't think that sourceforge is more trustable than github. To be clear: I don't insist on using the tarball from github; zip-file from sourceforge is fine for me, I just said what I would do. -- Alex
