Re: RFS: xfe (updated package - new upstream release)
Hi, Joachim.
On Nov 18 2009, Joachim Wiedorn wrote:
> Am Wed, 18 Nov 2009 12:56:08 -0200 schrieb
> Rogério Brito <rbrito@ime.usp.br>:
>
> oh oh, so a long list!
Well, I thought that you wanted some comments. :-)
> I still have not understand the difference between README and
> README.Debian. Perhaps that's the problem. So I will delete the part
> about installation thinks.
README should contain generic comments about the package itself.
README.Debian should contain comments about the package in Debian, like
some divergence in behaviour against upstream that users should violate
the principle of least surprise.
Other things that are pertinent in README.Debian: design decisions that
are taken in Debian, like reserving a given runlevel or allocating a
namespace of something for use in the distribution (say, all config
files with prefix 00 to 40 are meant to be used for tweaking something
in the kernel etc).
> With the background that the old package with version 1.04 was very
> old and for the new standard 3.8.3 plus cdbs and other thinks I have
> to create the hole debian directory new (with dh_make). Or should I
> ever let the first line in debian/copyright as it was in the old
> package?
You should still give a hint (a short phrase is enough) that other
people worked on the package and give them credit.
Talking about cdbs, it may obfuscate some details that you need to know
once you have to hunt some bug on your package and, while it
encapsulates many things, it may change its behaviour in subtle ways.
It is, after all, a second layer of indirection regarding the original
configuration, compilation, and installation (the first being debhelper,
used by cdbs).
> > * you can remove comments from the watch file.
> Some lines came from the template.
Just kill them. The templates serve as examples for people to know what
values to put in the appropriate fields.
> This '-' should only help, if the compilation/packaging was interrupted
> and in the next run at this points it would stop because the final
> situation was not reached.
An error generated during the package building at a given stage should
not generate the target of the makefile.
It is, in some cases, better to abort things if you encounter an error,
but you, the package maintainer, should decide what is better.
(I, myself, usually turn on every sensible warning, break at many
potential errors and warnings etc, just to be on the safe side).
> On the other hand I see the error message and can decide, whether it
> is a real error.
Nice.
> How should I understand this? In Xfe the "mount warning" is useful for
> NFS and other shared media, if they are no more exist. That could be
> activated from the user by local configuration.
Well, I will have to check it to see what happens.
> > * why do you have two patches to xferc? The patches have no comments on
> > them (See DEP-3).
> I should use better names for patches.
Right. If you find some time, just put a description there so that
people that will possibly make a non-maintainer upload understand why
the patch is there.
> > * why does it get compiled with -O3? Why not -O2? Why not -Os
> > (especially useful for machines without a lot of cache).
> I think this should be checked together with upstream - that's right?
No, this one should be fixed. Getting rid of the unconditional -O3, the
-ffast-math, -fomit-frame-pointer and so on should be done as a way to
control how the builds happen.
1 - Somebody may want to use the (Debian-policy described) variable
DEB_BUILD_OPTIONS=noopt to disable optimization (to hunt some potential
bug), but, as you package is right now, it always compiles with
optimizations turned on.
2 - The optimization level -O3 may be broken on some architectures (and
it was, if memory serves).
3 - Some other options are broken in other architectures (like, say, the
math-handling functions in ARM).
These options get set in configure and configure.in. You can change
those and convince upstream to flexibilize things a little bit.
All this is preventing you some quite possible headaches once your
package gets to the users systems.
> > * can't you compile the C++ code with -Wextra and -Weffc++? This way,
> > more warnings could be emitted and some potential bug that is lurking
> > there would just be discovered soon.
> I can do it for testing. But I think this is the job for the upstream
> developer, isn't it?
Yes, it is. But it already reveals some code improvements.
Oh, as a last point, just give a look at the output of lintian. It's
telling some things that are ultra-easy to fix.
That's it. I hope that your package gets into Debian ASAP. I'm using a
copy of it already.
Regards,
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Reply to: