Bug 24896 - new printconf could co-exist better with old printtool
new printconf could co-exist better with old printtool
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: printtool (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
Aaron Brown
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-24 19:23 EST by dunwoody
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-24 19:23:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dunwoody 2001-01-24 19:23:11 EST
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
didn't happen.

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
without installing
      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
/etc/rc.d/init.d/lpd, seems
      to mess with file permissions in a way that prevented my setup from
working.  Specifically,
      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
environment.
Comment 1 Crutcher Dunnavant 2001-02-01 16:45:44 EST
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.

Note You need to log in before you can comment on or make changes to this bug.