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 tk4.1 > - 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 rtfm. 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. Thanks, Kristis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
