Re: Python Packaging Guide
On 18/04/10 01:01, Jakub Wilk wrote:
My general impression is that it's yet another (very) bad piece of
documentation. Feel free to ignore my opinion however, as I'm already
prejudiced. :P
It's hard to ignore your opinion (or for that matter, that of any DD
here). When you say very bad, it is clearly more than just the factual
errors you've listed bellow. Could you explain what you said in more detail?
Okay, and here are some factual errors:
It is important to emphasize here that we should not touch anything
from the upstream source (except for special cases, [link to bug
#560287] which haven't been documented very well as yet).
This is stated in a very confusing way and I'm not quite sure what do
you meant here. It is very well documented when original source
should/shouldn't be repackaged (DevRef 6.8.7); versioning scheme is
just a detail. But nobody calls repacking .orig.tar.gz "touching
upstream source"...
Would it make sense to replace that whole sentence with:
It is important to emphasize here that we should not change any of the
upstream source while packaging. Sometimes, in order to comply with
Debian policies such the Debian Free Software Guidelines (DSFG), some
files may need to be
[[http://www.debian.org/doc/developers-reference/best-pkging-practices.html#repackagedorigtargz|added
or removed to the upstream tarball]]. All packaging work takes place
only inside the debian/ directory.
[you] should consider using [markdown] the next time you need
something to format your plain text
Erm, real pythoniasts ;) use reStructuredText for that purpose.
I wouldn't want to say that before continuing on to packaging markdown,
would I? :P
${misc:Depends} is debhelper magic. debhelper keeps track of all the
dh commands (don't worry, we'll come that soon) that we use and
ensures that our package depends any other package that is required
to run the command we do.
Please don't call "magic" things that are simple and documented (see
debhelper(7)). Besides, this description is highly confusing.
I see what you mean. I'll rewrite that.
A little bit of looking up tells us that ElementTree is already in
python by default, which leaves us with only Python to depend on.
This is true only for Python >= 2.5, and python-markdown is supposed
to support 2.4, too. Besides, standalone ElementTree use a different
module name that the one in the standard library, and not every piece
of software is prepared for that. (IIRC we had to patch a few packages
in order to be able to kick python-elementtree out of unstable.)
I should have been a bit more careful when I looked that up. What
confuses me is that the package in Debian depends only on python (that
too >=2.3) and python-support.
Would certainly be glad if you explain your reasons considering it to be
a 'bad piece of documentation'.
Thanks,
Umang
Reply to: