Notices

I've packaged Traceroute for Linux as traceroute2 to avoid a name collision with traceroute from the Fremantle SDK. It is available in extras-testing.

From the project's home page:
It replaced the old BSD traceroute in Debian distributions in August 2007.

It provides all the functionality of the BSD traceroute, tcptraceroute and iputils-tracepath packages.

Some usage examples:

Traditional UDP traceroute (default)
ICMP ECHO traceroute (as in Windows NT's tracert)
TCP SYN traceroute (default destination port 80, http)
TCP SYN traceroute (specify destination port 443, https)
TCP SYN traceroute (specify destination port 443, https, and print flags of final reply)
Useful for checking if an application is listening on the port.

Note: $ prompt above means unprivileged user, # means privileged (root) user.

Quite the 'Mr Traceroute' you are, at least judging from the app manager. Thank you.

I'd like to upload a new version to extras-devel, but first I'd like to see the stable version enter extras.

Please test and vote:
http://maemo.org/packages/package_in....0.18-0maemo1/

Can you clarify why you thought having this name-conflict with traceroute in the SDK repos is a problem? Neither dpkg nor apt-get have any problems with same-name packages being available in different repositories.

Anyway, gave it a quick test (don't use it regularly, as I already have nmap installed and nmap's companion nping has a more verbose traceroute functionality installed), looked over the inst/rm scripts, etc. Didn't spot any problems I'd consider worthy of blocking it over (though I can't test the IPv6 traceroute presently), so I upvoted it.

Sidenote: It /might/ be a good idea to have it do a dpkg diversion of the likely to conflict filepaths, such as /usr/bin/traceroute and /usr/bin/traceroute6. As is it clobbered my busybox-power symlinks at those paths when it uninstalled (I think it's better to have such diverts set up, esp. for busybox-power, because they can coexist just fine, they just both want to use the same path names).

I would have to request to become a maintainer of the traceroute package, and who would respond to that request?
Also, I didn't think we could update packages from the official repositories (although I'm not clear whether SDK counts as official).

Would it be better to fix this in busybox-power?
Does the same happen if you install traceroute from the SDK?

Well, we can't update the packages in the official repositories, but I thought there wasn't anything preventing you from uploading a package with the same name to the extras-devel repo, and promoting it down from there... I could be wrong.

Now, the problem we face is that Hildon Application Manager treats packages from the official repos (though I don't think that includes SDK repos) as sacred vs. the ones in extras, so it will not install upgrades with the same name from extras. I wrote a whole ramble about why I think that's flawed several weeks ago somewhere around here, because it's clearly a relic of Nokia's corporate/business rules imposed on their wrapper around apt, and not in my opinion technically sound. At any rate, I thought apt-get would still happily install the updated versions, or at least would allow a user to do so manually.

So, if the SDK repo is not treated as special, then there's no issue. If it is, then from a user-friendliness perspective, I see your point.

I'd say no. If package A provides a working /usr/bin/foo, it's not package A's fault if package B installs another /usr/bin/foo over that already installed one. I mean, I could apt-get install --reinstall busybox-power, and it'll reset fine.

I'm not sure what busybox-power is supposed to do about this. Put its symlinks into non-standard paths, or divert other packages' files into non-standard paths? For something that touches as many pathnames as busybox-power does, I wouldn't vote in favor of that.

But it's a moot point anyway: I wasn't strongly convinced traceroute("2") should do anything about this to begin with, and after some fiddling with dpkg-divert, I don't think it's really the right solution here - it's unsustainable if many packages started to divert the same pathname...

Haven't gotten a chance to test it. From experience though, I'm going to say "probably".

IMO we should be fixing packages not making new packages with different names.
If that means adding to CSSU or extras-devel for now, that's the best option.

If it breaks something on uninstall that would be a blocker IMO.

Well, you can't count it undoing two busybox-power symlinks against it - like every tool does that: tar will clobber busybox-power's tar symlinks last I checked, ping will definitely clobber /usr/bin/ping, etc.

It's just the nature of what busybox does: it puts symlinks to itself in a bunch of filepaths, and if you install any more full-fledged utility, you lose your symlink. Consequently, although I initially suggested considering doing something about it, on further thought I would not consider this a bug of the traceroute2 package, at all.

Traceroute for Linux 2.0.18-0maemo1 has received enough votes and has been promoted to Extras.

Unfortunately, it has been so long since I posted the following, I have no idea what it was about.