naming conflict with "click modular router"

Asked by peter swain on 2013-09-14

I like the concept of click packages, but when this dribbled into my ubuntu-13.10 system yesterday it didn't install.

Why did install break?
because I already have a /usr/local/bin/click, from the "click modular router" project, an active multi-OS development project which has been evolving since 1999 on linux & netbsd, with 10000+ commits, multiple commercial forks & several international conferences.
See http://www.read.cs.ucla.edu/click/click & https://github.com/kohler/click/

That Click isn't in Debian/Ubuntu universe package lists, because it's never a one-click install.
Kernel patches are required, so it's not for newbies, but the essence of the project is to provide a wormhole where packet flow can be directed thru a graph of dynamically lodable/configurable filters in kernel & userspace.
Develop new packet processing in the security of userspace & promote modules into kernel for efficiency with no code change.

As someone with interest in both Ubuntu Touch & Click Modular Router this distresses me,
I see an ugly conflict downstream where someone has to change all their docs to alter command name for some platforms.
Ironically I'd recently installed click router on my ubuntu box to begin developing a concept which would deliver onto mobile platforms.

While I recognize that your click has precedence in that it is the first user of the command name 'click' in a package registered the Ubuntu/Debian package space, perhaps you could consider renaming the command as click-pkg or clickp or something to resolve this conflict.
Otherwise, when the other click does get incorporated into debian/ubuntu universe (and I might do it, if noone gets there first),
it will mean customizing scripts & searching 300+ manual pages for places to either bend the name, or insert a $PATH fix.

I mention it because click packaging hasn't yet hit any stable distributions, having ~6 months of history, so bending the name before it hits mainstream 13.10 would cause less overall frustration now, than either a later name change in either command, or adding a $PATH tweak into many linux-based click-modular-router projects, so they don't meet this conflict when click-packager goes into mainstream ubuntu/debian.

If I do get off my good intentions & package the other click for ubuntu/universe, I'll add an alternate invocation as click-mr (or similar), and bend the configure/install to _not_ install /usr/local/bin/click when /usr/bin/click exists. That way there's a dis-ambiguation path forward, using the unambiguous name in all scripts to avoid messing with $PATH, but allowing unmodifed scripts to work when click-packager is not installed.
Please consider doing the same at your end.

Workaround?
I did
# sudo mv /usr/local/bin/click{,-mr}
to allow co-existence, so Ubuntu-13.10 can 'apt-get upgrade' without grief.

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu click Edit question
Assignee:
No assignee Edit question
Last query:
2013-09-14
Last reply:
2013-09-16

I suggest you report a bug. Saucy is not ready and not stable in any way. It is not for casual users
 You will get a lot of feature holes and issues up to and even after release.

If you need an OS that works I suggest you clean install Precise which is not only designed to be rock solid but is LTS and supported til April 2017 which is far beyond the support of Saucy

Can you help with this problem?

Provide an answer of your own, or ask peter swain for more information if necessary.

To post a message you must log in.