hydrogen-drumkits package

[IOhannes m zmölnig]

On 09/16/2015 10:41 AM, Jaromír Mikeš wrote:
> Ok ... if we thinking packaging these files what about licensing?
> There is already one bug opened ...
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773246
> 
> IOhannes can you suggest complete list of packages we could provide
> and containing drumkits?
> 


i don't use them, so i'm probably not the best person to ask :-)

however, i took a look at the package, and here is what i think:

- first of all, upstream doesn't "release" (in a formal release-process)
drumkits at all.
i don't think that attaching the hydrogen version number to the drumkits
is a very good idea in the first place (sticking with the date of the
snapshot is saner)


- upstream doesn't even provide a tarball for the drumkits.
instead we (Debian) create a fake tarball by aggregating all downloads
published via their drumkit feed (DKF).

that's a slightly awkward situation.


- the DKF provides some extra information (author, description,
license,...).
since the upstream tarball is synthesized anyhow, this information could
be used to synthesize debian (binary) packages as well: just provide a
single drumkit per package¹.

the biggest problem i see here, is that this makes the number of Debian
packages variable.
otoh, if we are not doing too many snapshots and keep old drumkits (not
published by upstream any more), then the work should be reasonable.

i *think* this should be done semi-automatically, using a script
downloading the drumkits and providing a debian/control stub that has
all the information updated.




- licensing is a *complete* mess.
the DKF is kind enough to provide licensing information provided by the
authors (in a free form; so not really machine parsable)
cool.
the bad news is, that many drumkit package creators did not care about
licenses, and just left the license field empty :-(

worse, some drumkits have a license text like:
 "Do not redistribute or publish the inluded samples."
here's a list:
 - GSCW Kit 1 (Flac edition)
 - GSCW Kit 2 (Flac edition)
 - Roland_MC-307_CR78&Cheaps
 - Roland_MC-307_TR-606
 - Roland_MC-307_TR-808_
 - Roland_MC-307_TR-909
 - Roland_MC-307_Techno1


which leaves only these drumkits that have a free license (mostly some
CC; and 'Lightning1024' says "Free!" whatever this means)
 - DeathMetal (sf)
 - circAfrique v4
 - BJA_Pacific
 - The Black Pearl 1.0
 - Gimme A Hand 1.0
 - rumpf_kit_z01_gm
 - belofilms.com - AC-Guitar-Strums (flac)
 - Audiophob
 - Drumkit excepcional
 - Lightning1024
 - Denon CRB-90

that's still 194MB, but having a closer look reveals, that 136MB of
those are consumed by "belofilms.com - AC-Guitar-Strums (flac)".
which is not a proper drumkit at all, so i guess it could be factored
out into a separate binary package.
i haven't checked the rest, but if they are all "drum" kits, then we
might want to put them into a single package (~58MB).
or split them into something like:
- hydrogen-drumkits-classical
- hydrogen-drumkits-ethno (or hydrogen-drumkits-percussion)
- hydrogen-drumkits-electro
- hydrogen-drumkits-effects


mgfdsr
IOhannes


¹ yes, even though i said that was overkill in my last mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150916/82ce0f07/attachment.sig>