debathena-lprng should be providing /usr/sbin/lpc

[geofft]

I can't tell if this has been happening since debathena-printing-config 1.17 (the version where we rewrote everything to be awesome in the brave new CUPS world), or since a recent CUPS update, but all the /usr/sbin/lpcs that I find are CUPS' version. In the words of 1.17's changelog, lpc is "only useful with LPRng", so this is wrong. Either printing-config should restore a wrapper for lpc that unconditionally calls mit-lpc, or debathena-lprng should divert cups-bsd's lpc out of the way and drop its own in place.

[andersk]

I disagree. Just because CUPS lpc isn’t useful to _you_ doesn’t mean it isn’t useful to any CUPS users, or that it’s okay to unconditionally break that functionality for CUPS printers. Also, at this point any damage that was going to be done is done and people know they need to use mit-lpc.

(Zephyr discussion ensued about how little functionality CUPS lpc has. I maintain that you’ve only shown that it isn’t useful to you.)

(Zephyr discussion also ensued about how lpc may be useful to maintainers of private Athena queues. I maintain that they know they need to use mit-lpc and can continue to do so.)

[andersk]

If you guys are hell-bent on diverting lpc because you think the Athena 9 lpc syntax needs to be supported for legacy queues forever (even if the lpr syntax for legacy queues won’t be, according to my understanding of the current plan), what do you think about instead putting ‘alias lpc=/usr/sbin/mit-lpc’ in the dotfiles if debathena-printing-config is installed?

This has the advantage that we don’t need to divert CUPS binaries, and also that it works without /usr/sbin in the PATH.

[geofft]

Replying to andersk:

Also, at this point any damage that was going to be done is done and people know they need to use mit-lpc.

For the record, I think this is terrible logic. First, new maintainers of private LPD/LPRng queues (and they will continue to exist until we have a good solution for access-restricted IPP queues) shouldn't need to know about our previous mistakes. Second, the fact that people have probably learned a workaround does not mean we should avoid fixing the bug, especially when the fix won't break the workaround. Lastly, I think this attitude inspires poor quality in the project; we should strive to fix our bugs, if for no other reason than that the next time we look at the printing system, we shouldn't need to figure out if quirky behavior is intentional or is just a facet of us wanting to not fix our bugs.

As a specific technical point, I think I may have used lpc maybe three times on all the Athena cluster printers in the last year of LPRng printing, so I'm unconvinced that a couple of months is sufficient time for the majority of private queue maintainers to have had a need to use lpc. Certainly I ran into this when poking at the sipbmp3 queue (which has its own lpc specialness that is irrelevant to this discussion).

I don't think the rest of your two comments are worth replying to; we've had this discussion on zephyr already, and I stand by what I wrote in the original bug report.

[jdreed]

Replying to andersk:

If you guys are hell-bent on diverting lpc because you think the Athena 9 lpc syntax needs to be supported for legacy queues forever

No one is suggesting that it be supported "forever", I think we're all looking forward to the day when we kill LPRng with fire.

I don't think debathena-lprng should provide /usr/sbin/lpc, however. I think the right thing to do here is to have printing-config divert lpc and install a wrapper, like it does with every other BSD printing command. If you have printing-config installed, you have decided (or had it decided on your behalf) that you want our special unique precious-snowflake printing environment. In that case, I don't think diverting lpc is any more or less wrong than diverting lpr, lpq or lprm.

I really dislike the idea of putting an alias in the dotfiles. There's no guarantee they'll get run (a user could pick an awesome shell or something), and frankly, we do enough mucking with printing, that I'd like it to all be done in one place, by one mechanism, so that we can easily tear it out once we nuke LPRng from orbit (it's the only way to be sure).

[andersk]

If this is implemented as a wrapper that works for both CUPS and LPRng queues like all the other printing-config wrappers, then none of my objections apply. My sole objection here is that there is poor justification for changing the behavior of an upstream command in an incompatible way.

[jdreed]

A wrapper is not that hard:

• The only "lpc" command that CUPS lpc support is 'status'. So if the user runs "lpc status foo", then use the same logic as the other wrappers to figure out whether "foo" is a CUPS or LPRng queue, and run the right command.
• For every other invocation of lpc, assume LPRng.
• For interactive mode, assume CUPS, possibly whining on STDERR about how the user should run /usr/sbin/mit-lpc if that's what they wanted.

The one screw case is "lpc status all" which is a valid cups and lprng command. In that unique case, we can either decide to run lprng, decide to run CUPS, or yell at the user, or something.

[jdreed]

The one screw case is "lpc status all" which is a valid cups and lprng command. In that unique case, we can either decide to run lprng, decide to run CUPS, or yell at the user, or something.

In fact, "lpc status all" has never worked on Athena, so it can run the CUPS one. The other ambiguous commands are "lpc quit" (which the CUPS lpc doesn't support, despite claiming that it does:

jdreed@infinite-loop:~$ lpc help
Commands may be abbreviated.  Commands are:

exit    help    quit    status  ?
jdreed@infinite-loop:~$ lpc quit
quit is not implemented by the CUPS version of lpc.

"lpc help" can do something clever, possibly even printing our own help message and then directly users to run cups-lpc help or mit-lpc help.

[broder]

While I'm not working on this issue specifically, I'm currently doing a fairly substantial reorganization of printing-config that will conflict with anybody attempting to work on this.

On the upside, it'll make solving this ticket much easier.

[broder]

Ok - I've finished my substantial refactoring of printing-config, so anybody who is interested in working on this should feel free.

[jdreed]

I'm tempted to wontfix this, since we're killing LPRng with fire.