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

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
latest version.
> - 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
> abilities.

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 debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: