Hello Thibaut, > I know the packages need more work (in particular concerning the > copyright files, removing commented-out dh_*lines in rules and > rebuilding under sid), so I am not requesting a detailed review, but I > think advice on the following few questions would be timely: That's always a good idea. > * package granularity: I have currently 7 add-on packages (one more > coming soon), each one rather small (few 100K each) but coming from a > different upstream and depending on different libraries (like libtiff, > zlib and other). Should I keep these add-ons separate or compile a > single yorick-addons package? (I need this question sorted out before > I start filling ITP bugs). With 'different upstream', do you mean different upstream tarballs and upstream authors? Then I'd stick with the one-source-package-per-upstream approach. Merging stuff from different upstream sources makes sense when they are very numerous and/or very small. They do not seem to be exceptionally small, nor is there a very big number of them. By the way, the dependencies are only relevant to binary packages. So if you merge them into one source, you could still create separate binary packages for each add-on with its own dependencies. > I have the reversed question for the upcoming package (yeti, > http://www-obs.univ-lyon1.fr/~thiebaut/yeti/yeti-6.0.2.tar.gz ) > which is indeed 4 plugins: a set of general purpose utilities, and > wrappers for regex functionnalities, libtiff and libfftw2. If I stick > to one package per plugin, should I split this one? Ok, are you talking about source or binary packages here? For source packages, the reasoning might be the same as above. > * name space: I prepended yorick- to each upstream name to help users > find out what add-ons are available, comments welcome. Some upstream > names can really not be left untouched: e.g. "curses" for the curses > wrapper... Of course this question is resolved if I go for a single > package. I think prepending 'yorick-' to the package names is a sensible thing to do. > * version numbers: upstream Yorick is named "2.1.02" although it is very > regularly updated on cvs. I'm currently sticking to 2.1.01cvs<date> > to be ready when an official 2.1.02 is released. The upstream author > (and former Debian packager) is ready to create a CVS tag to give some > substance to the version that will eventually go into Debian, even if > not making a point release. Do you have any piece of wisdom with that > respect? (Note that the CVS version contains changes I asked for for > better Debian policy conformance, so I don't want to package the > already released version 2.1.01). > > If I go for grouping all the add-ons in a single package, what version > numbers should I use for it? It should be sensible. Is there a common denominator in the version numbers of all the contents (e.g. they all start with abc) then you could use that as a basis. If there's absolutely no connection at all between the version numbers, you could use the date you put them all together. Thijs
Attachment:
signature.asc
Description: This is a digitally signed message part