[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: bzr-cvsps-import

OoO En  cette soirée  bien amorcée  du lundi 04  août 2008,  vers 22:53,
Jelmer Vernooij <jelmer@samba.org> disait :

>> I think that  most things in Build-Depends are not  needed for the clean
>> rule, so  you can move them  in Build-Depends-Indep (and  just keep cdbs
>> and debhelper).
> Fixed.

Please  Build-Depends-Indep  on  python,  even  if it  is  currently  an
indirect  dependency.  For  bzr-stats,  you  need to  move  python  from
Build-Depends to Build-Depends-Indep since it is not used on cleaning.

>> To avoid a lintian warning,  you should provide a debian/watch file with
>> just a comment about, for example, the URL to upstream repository.
> Fixed.

You put a real debian/watch file.  However, since you are tracking a bzr
branch, this is a bit useless. Just put some comments in it instead of a
real URL:
# This package uses the following bzr branch:
# http://....

Like you did for bzr-stats in fact.

>> Well,  this may  be a  bit late  since some  packages have  already been
>> sponsored,  but since  all those  plugins  are rather  small, you  could
>> bundle them in  a single package (like gnus-bonus-el  for example). This
>> will be a  bit harder to follow upstream since there  is no mechanism to
>> track  several upstreams  but  this will  ease  your work  in finding  a
>> sponsor, I think  and will allow you to ship more  plugins once you will
>> get an  upload with DM  field enabled. I  am not sure this  is something
>> encouraged or  something to  avoid. Maybe some  people will  give better
>> advices here about this.
> Even if it's all inside a single source package, it would still be
> necessary for the package to go through NEW whenever a new binary
> package is added. Putting the multiple plugins into the same binary
> package is probably a bad idea since they each have different
> dependencies.

I was thinking about one source  package and one binary package. No need
to go through NEW then. But you are right about dependencies.
  * For moronic filesystems that do not allow holes in file.
  * We may have to extend the file.
	2.4.0-test2 /usr/src/linux/fs/buffer.c

Attachment: pgp4HRZODJfmR.pgp
Description: PGP signature

Reply to: