Bug 24896
| Summary: | new printconf could co-exist better with old printtool | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | dunwoody |
| Component: | printtool | Assignee: | Crutcher Dunnavant <crutcher> |
| Status: | CLOSED WONTFIX | QA Contact: | Aaron Brown <abrown> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | Keywords: | FutureFeature |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-01-25 00:23:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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.