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

Re: [RFS] python-lockfile 0.7-2



On Fri, Mar 06, 2009 at 08:59:17AM +1100, Ben Finney wrote:
> Don't I need to depend on ‘python-all’? Since the package is to be
> installed to *all* Python versions in Debian, not just the latest one.
Because you are only copying, it should make no difference. You only need
python-all if you have to call setup.py with different python versions.

You simply don't need python2.5 and python2.4 if you just want to call
python. And that's what 'dh' does.

> Also, should the build dependency on Python be ‘Build-Depends’ or
> ‘Build-Depends-Indep’?
dh_auto_clean runs python setup.py clean, and therefore Python has to be
in Build-Depends as it is needed for the clean target.

> In general, though, what's the guideline for how non-changelog the
> file contents can be before it's not really appropriate to use it as
> the upstream changelog? Many upstream packages contain a “notes to
> the user about recent releases” file, which would be more appropriate
> as ‘NEWS’ in a Debian package.
I do not think that there is a guideline, at least I do not know of
any. Generally, you can treat the file which contains more entries
as the changelog.

> I must agree with others in this forum that it's easier to track the
> differences between different releases if they actually have different
> release numbers.
I generally treat mentors.debian.net in the way I treat a temporary
branch in eg. git. I develop a particular feature in this branch and
then squash-merge it into master, and only a summary of all changes
made in the other branch, relative to master.

And in Bazaar, if you merge a branch you also get a top-level message,
and the merged commits are simply sub-revisions.

And in your case, you are using a VCS to develop your package, which
means you still have all your changes there.

> Normal white space: ASCII FF, a page break. I use them because they
> are useful for navigating a text file “by page” in the editor.
Interesting. I haven't seen anything using it, and at least my editor
simply prints "FF" (with a black background).

> I have been following the progress of the specification, and haven't
> seen any format changes that would affect any copyright file I work
> on. Can you point out the changes that affect this copyright file?
Well, you have changed it again to allow the symbols for copyright,
so this particular problem is gone (but it was in revision 440).

But I can not see that 'Expat' is listed as a valid value for 'License'
anywhere.

> What's the reasoning for that? Any indentation is sufficient for
> conforming with the format specification (since it's sufficient for
> conforming with the RFC2822 field format). Given the choice, I prefer
> to indent with 4 columns.
OK, but most people actually use 1 space, and you don't use 4 spaces in
debian/control either.

-- 
Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member     - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juliank@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/


Reply to: