On Sun, May 29, 2016 at 07:25:44PM +0100, Edd Barrett wrote:
> On Sun, May 29, 2016 at 07:56:34PM +0200, Sebastien Marie wrote:
> > I prefer to keep it as it for now: a more "automatic" way will not be
> > able to copte with -YYYYMMDDnn format if I need to build more than one
> > archive some day.
> 
> Alright.
> 
> So I can't vouch for the magic in post-extract, but I don't see anything
> completely bonkers.

the magic is requires to make cargo (bootstrapper) to think it doesn't
need to do any network access. there is no automatic way build in
cargo to make it depend only on local filesystem. so I rebuild a
registry (cache, src, index) as cargo would have build it alone.

but I agree it is not a very clean method... but I don't think it could
be better for now.

> The last few comments I have:
> 
> > - Invokes rustc or another build tool with the correct parameters to build 
> > your
> 
> Lines in DESCR needs to be no more than 72 wide. Usually you can use
> `fmt -72`, but I think that will break your bullet list.

portcheck makes the verification on 80 wide. I will reformat before
commiting.

> > PERMIT_DISTFILES_FTP = No as hamcrest has no license information
> 
> After you import this, can you follow this up? Not having a package on
> ftp is going to be pretty annoying.

there is already one issue opened for proper licensing (dual MIT/Apache 2.0).
but as there are many contributors, each of them has to relicensing his
contributions: https://github.com/carllerche/hamcrest-rust/issues/22
and some previous contributors seems also inactive now :-/

but as hamcrest isn't build with cargo (it is only used in the test
suite), the cargo package is ok for distribution: it is only the
distfiles that can't be mirrored.
-- 
Sebastien Marie

Reply via email to