Re: sponsor and advocate wanted
On Tue, 2002-06-25 at 11:06, Ben Armstrong wrote:
> On Tue, Jun 25, 2002 at 02:01:46PM -0300, Ben Armstrong wrote:
> > On Thu, Jun 20, 2002 at 09:24:27PM -0700, Kristis Makris wrote:
> > > tkxcd - a diff front end with a look and feel based on Atria Clearcase
> > > xcleardiff. Similar to tkdiff. Outdated, but upstream has a much
> > > improved version that I'm pushing him to formally release.
> > This one looks interesting. I'm taking a look right now.
Hi Ben, thanks for your comments and time.
> Never having seen Atria Clearcase xcleardiff, I don't know how close this
> utility comes to its look and feel. However, comparing it to tkdiff and
Neither do i.
> xxdiff, I don't see anything in this package that would recommend it above
> these more mature visual diff programs already in Debian. Can you help me
> out here? Have I missed some obvious advantage that tkxcd has over tkdiff
> and xxdiff?
The newer version that I'd like to see the upstream release allows
displaying two files one below the other, rather than left and right. I
found no way to do this in tkdiff or xxdiff, if there is one, and is the
main reason I use tkxcd.
> Moving along to some general observations about your packaging:
> - You include ./debian/menu, but it does not work because arguments must be
> provided to the command. Therefore you should remove it. You can add it
> back later if/when tkxcd supports being started with no arguments.
> - Why do you depend on tk8.0 in particular? That is a bit dated. Will
> tk8.3 not work? If more recent versions work, specify a dependency
> on tk8.3 or earlier versions with: Depends: tk8.3 | wish
As a matter of fact the minimum requirement is tk4.1. How can I express
that since there's no tk4.7 package in woody? Should I simply set a
Depends: wish ? How can the package also be installed on older Debian
systems (e.g. potato) where tk4.1 is available? I understand that it
cannot be officially part of potato now, but I'd still like to have the
option of installing it on an older Debian. If I recall correctly
dpkg-buildpackage (or lintian) complained that there's no package called
> - You make the package priority "optional". I would say "extra", given
> that tkdiff and xxdiff both already provide more functionality than tkxcd.
> - The URL you give in copyright gives me a 404. Is there a new home page
> for tkxcd?
I'm waiting for upstream to make a new one, along with releasing the
> - You unnecessarily create /usr/sbin in the deb because you did not delete
> it from ./debian/dirs (dh_make put it there).
> - You unnecessarily leave in unused and/or commented-out dh_* routines
> in your ./debian/rules file. Find the ones that aren't needed and
> delete them, thereby improving readability of the makefile.
> - Similarly, configure & configure-stamp do nothing. Eliminate these
> targets and all references to them.
> - Under build (which is mandatory) you do nothing. Instead of leaving
> dh_make's comment in, you might replace it with a comment simply stating
> that tkxcd has nothing to build.
> - The DEB_HOST_*_TYPE variables are not needed. Neither are the
> DEB_BUILD_OPTIONS if statments that set switches that would only
> be used during building & installing a binary program, which you
> don't do.
> - You include TODO in ./debian/docs but not README. Why not? Yes, I
> can see README contains some install notes, but it also has valuable
> user information in it not also in the man page (see the "Bug Reports"
> section at bottom). Including a README with install notes in it is
> not without precedent in Debian. I see it all the time, and for
> similar reasons as in this case: after the install notes often comes
> some valuable information for the end user.
> And finally some comments about the program itself:
> - I found tkxcd segfaulted and core-dumped on me upon reaching the bottom of
> a file which ended with trailing nulls (an artefact of copying the files
> over SMB from a Pathworks server)
> - When advancing from one diff to the next, and both differences are visible
> in the same screenful, the window does not advance, nor is there any
> visible indicator that we are now viewing the next difference section.
> This has the "feel" of being broken. When I press a button, I expect
> something to happen visibly.
> - Providing a '-rcs' switch is a nice touch, but nothing new, since tkdiff
> provides this, and more. Tkdiff will also do cvs, which is far more
> common than rcs these days anyway. (Yes, I know you warned that the
> package was out of date.) I did not test the -rcs switch, so I can't
> say whether it works as advertised.
> I have only looked at this packages as it is the only one that interested me
> personally. Perhaps this was an early attempt and you have since learned to
> make more polished packages. If you want to make a good impression on a
> would-be sponsor or advocate, my principal advice to you is to pay careful
> attention to the stuff that dh_make automatically adds for you and make sure
> all the rough edges are gone before you announce your package to the world.
Thanks again for all your comments.
I would claim that most of my decisions during packaging where results
of having a hard time finding clear documentation in either a detailed
or "Guide" style. I've found the NM's Guide to lack a lot of
clarifications on even mere mentioning of certain features/techniques
used in packaging. I had been looking for "The Packaging Manual" for a
long time, after seeing it casually referenced by other documents,
lintian, but never the NM Guide, and to this date I do not know which
package provides that, even though google spit back a link to it. I'm
frustrated with the documentation in general, and I do firmly believe in
What is the proposed way of handling RFPs or ITPs? Are all the packages
listed there first examined for their feature set and accepted/rejected
as being possible Debian package candidates? (or should they be)? If
there is (or was) such a process it could possibly save maintainers time
packaging software that is not generally liked.
> If there is another package you have made that shows off your packaging
> skills better, perhaps you could let us know so we could better assess your
xsb received most of my packaging attention. I'm waiting for an official
2.6 release from upstream before I continue with it.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com