Red Hat Bugzilla – Bug 24896
new printconf could co-exist better with old printtool
Last modified: 2007-04-18 12:30:54 EDT
I just installed Raw Hide 20010122, and I enjoyed the opportunity to try
the new printconf-gui-0.0-5
tool. Unfortunately, it didn't work for my environment (see separately
filed bug). It appears to me
that the new printconf-gui is intended to eventually replace the old
printtool. If this is in fact the
case, I'm more than happy to be patient while the new printconf improves
and eventually becomes
strictly better than the old printtool.
In the meantime, however, I'd like to set up something that works (not that
I'm using Raw Hide in
a production system...) I found a way to go back to using
the old printtool-3.55-1 on my Raw Hide 20010122 system, and along the way
I observed some
ways in which this could be made easier. I think it's likely that some of
these issues have already
been addressed as I write this, but here goes:
1. I'm not sure exactly how, but the printtool and rhs-printfilters RPMs
got removed from my
system when I installed Raw Hide 20010122. If this was indeed
intentional, I'm not convinced
that it's appropriate or necessary, given the early developmental
stage of printconf/printconf-gui.
I think it should be possible for the old and new RPMs to coexist.
2. I'm not sure exactly how, but the existing contents of my
/etc/printcap file got blown away
when I installed Raw Hide 20010122. I was expecting that the
previous /etc/printcap would
be saved in a .rpmsave file, which would have been nicer, but that
3. I believe there is a missing RPM dependency somewhere here -- I was
able to install
Raw Hide 20010122, including LPRng-3.7.4-3 and printconf*-0.0-5
alchemist-0.7-1, which seems to be required by LPRng-3.7.4-3 .
3. After I ran printconf-gui and it failed with a bunch of errors (see
separately filed bug), a file
under /etc/alchemist was left in a state that prevented
/etc/rc.d/init.d/lpd from starting lpd.
It would be better if the /etc/rc.d/init.d/lpd script was more robust
against this type of failure.
4. After I restored the original contents of the /etc/alchemist files, I
was able to re-install
printtool-3.55-1 and rhs-printfilters-1.81-1, re-add my printers (all
of them are remote LPD
queues), and use /etc/rc.d/init.d/lpd start to get lpd going.
5. The only remaining problem was that printconf-backend, run from
to mess with file permissions in a way that prevented my setup from
the file /usr/lib/rhs/rhs-printfilters/master-filter, which is
symlinked into the printer entry dirs
under /var/spool/lpd, gets its execute bits turned off. I wrote a
little script to chmod this single
file back to proper execute permissions, and as long as I run that
script after starting/restarting
lpd, everything works properly for me again.
To sum up, if it's going to be a while before the new printconf is strictly
better than the old printtool,
then it seems to me that a very small amount of effort could go a long way
in helping the new
printconf coexist with the old printtool in a Raw Hide system. This would
make life much easier for
those of us who can't yet get the new printconf to work in a specific
The problem here is that the old printtool had no central repository for the
information about a given spool. It stored config information in printcap
(ick!), and diddled in the spool directories.
It is incompatible with the new printconf system (which I'd not thought about
inflicting upon the poor beta testers of the world when I pushed it through the
tree, oops.) It is /very/ incompatible with this system, because of keeping it's
meta information in printcap, which is now a generated file.
But, some answers to your specific questions:
1: It removed them because it 'obsoletes' them, being the replacement.
2: At install time, when it zapped rhs-printfilters, it ran a translation
script. The script succedded, but a bug in the alchemist fried the data. It now
produces a 'printcap.save' file when it translates.
3: Yes, the alchamist should have been required. this is fixed.
3(no2): Addressed in the other bug report.
4: no comment.
5: That wasn't printconf-backend tweaking permissions, it was lpd.init
I promise that printconf will not suck (or at least will suck less than
printtool) by the gold date. I think it is making mucho progress.