Bug#847350: RFS: golang-github-minio-minio-go/2.0.2+dfsg-1
Hi again :)
>
>I think "ds" is quite confusing let alone that it matches my initials. ;)
lol
>IMHO DFSG-repacking fits all cases even when we throw away useless files to
>avoid documenting their copyrights. Often you just don't know whether
>excluded content is DFSG compliant or not. And since removing bundled
>libraries is policy compliance I believe DFSG is the appropriate suffix to
>use in repacked tarballs.
yes, but in this case there is no license/copyright issue, at least I can't
see it
>I thought "debian/clean" is an unrelated issue... What about "debian/clean"?
>I sometimes remove 3rd party dependencies from "debian/clean" as well (not in
>this package as I recall). You may say it is redundant but actually it is
>useful if/when you re-build from non-repacked tarball or checkout of upstream
>repository.
>
>Here I think "debian/clean" was used merely to drop some tests (instead of
>patching 'em which would be more difficult).
exactly, and this still is the case, some tests needs remote connectivity, and needs
disabling.
debian/clean still fits this need correctly to me
>Only if there are bundled 3rd party libraries. Repacking is very common for
>Golang packages -- even dh-make-golang does that by default and it does not
>indicate that something was thrown away neither by adding "ds" nor "dfsg" to
>version...
ok, nice to know :)
>Correct.
thanks
>I'm sorry I think I've lost the context... Could you please ask your question
>again and I'll do my best to explain.
it is fine now, the whole point was
"please don't repack the tarball as dfsg just to exclude two tests (already there in
the current upload and excluded by debian/clean"
and your answer seems to have confirmed this point :)
>Thank for your help, Gianfranco. I did not have a chance to look at the >current state of the package yet. I'll see if I can have a look later today.
that would be awesome, thanks!
cheers,
Gianfranco
Reply to: