Re: Deleting uncompressed Info/Doc files at upgrades
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 16.10.98 in [EMAIL PROTECTED]: I disagree quite strongly. If the intent was to have uncompressed originals on the system we would have shipped them as such. Indeed - the .debs would be smaller that way. MfG Kai
Re: Deleting uncompressed Info/Doc files at upgrades
[EMAIL PROTECTED] (Peter S Galbraith) wrote on 16.10.98 in [EMAIL PROTECTED]: - If you are using some docs often on a 486, you end up uncompressing them because it's too slow otherwise. I'm using a 486. Uncompressing text is too slow? Ridiculous. On the other hand, I currently have about 16 GB of hard disk on this thing, and uncompressing docs is NOT a good idea because it costs way too much space even with 16 GB (as a rule, data grows to fill the available space). MfG Kai
Re: Deleting uncompressed Info/Doc files at upgrades
On Saturday 17 October 1998, at 21 h 56, the keyboard of Rob Browning [EMAIL PROTECTED] wrote: Unless you're logged in as root, you're not going to be able to build these example files inside /usr/doc (nor should you) anyway, so you'll have to copy them somewhere else. You can run gunzip on them then and there's no problem. It means that the sysadmin has to create /usr/local/doc, and, foreach package, create a subdirectory in it and uncompress the files in that subdirectory? Then, after each upgrade he has to do the same? After each removal, she has to remember to delete the subdirectory? To me, this completely defeats the purpose of having packages. I believe I'm reading the messages of Slackware fans explaining that building/installing everything by hand is not a such fuss.
Re: Deleting uncompressed Info/Doc files at upgrades
Hi, Stephane == Stephane Bortzmeyer [EMAIL PROTECTED] writes: Stephane On Saturday 17 October 1998, at 21 h 56, the keyboard of Rob Browning [EMAIL PROTECTED] wrote: Unless you're logged in as root, you're not going to be able to build these example files inside /usr/doc (nor should you) anyway, so you'll have to copy them somewhere else. You can run gunzip on them then and there's no problem. Stephane It means that the sysadmin has to create /usr/local/doc, Stephane and, foreach package, create a subdirectory in it and Stephane uncompress the files in that subdirectory? Then, after Stephane each upgrade he has to do the same? After each removal, she Stephane has to remember to delete the subdirectory? Staw man. You mean you really build all the examples in all packages? really? Set up a cron job to clean all /usr/local dirs after no mods in a month., Set up a cron job to cp -a dirs after changes in /usr/doc. In reality, one really only compiles examples in a handful of packages, and one can do that anywhere. Stephane To me, this completely defeats the purpose of having Stephane packages. I believe I'm reading the messages of Slackware Stephane fans explaining that building/installing everything by hand Stephane is not a such fuss. You are entitled to your opinion. I am entitled to my opinion of your opinion. manoj -- hacker, n.: Originally, any person with a knack for coercing stubborn inanimate things; hence, a person with a happy knack, later contracted by the mythical philosopher Frisbee Frobenius to the common usage, 'hack'. In olden times, upon completion of some particularly atrocious body of coding that happened to work well, culpable programmers would gather in a small circle around a first edition of Knuth's Best Volume I by candlelight, and proceed to get very drunk while sporadically rending the following ditty: Hacker's Fight Song He's a Hack! He's a Hack! He's a guy with the happy knack! Never bungles, never shirks, Always gets his stuff to work! All take a drink (important!) Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Deleting uncompressed Info/Doc files at upgrades
Antti-Juhani Kaijanaho [EMAIL PROTECTED] writes: M-x toggle-auto-compression M-x auto-compression-mode Just put (auto-compression-mode 1) in your .emacs. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: Deleting uncompressed Info/Doc files at upgrades
Zed Pobre [EMAIL PROTECTED] writes: I don't agree here. Some programs have included example files that are either c files that (unless there's a trick I don't know about) will not compile compressed, or example data files that cannot be read by the program in question compressed. The svgalib package(s) comes to mind as an example. Should I file a wishlist bug against policy that files meant to be compiled or used by programs otherwise not supporting gzip be left uncompressed? Unless you're logged in as root, you're not going to be able to build these example files inside /usr/doc (nor should you) anyway, so you'll have to copy them somewhere else. You can run gunzip on them then and there's no problem. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: Deleting uncompressed Info/Doc files at upgrades
Michael Stone [EMAIL PROTECTED] writes: Hmm. We have zless to less gz'd files. Magicfilter will print them, as will a2ps (maybe some others will too, haven't tried it.) Netscape reads them, so does lynx. And of course man and info work with them. zgrep will grep them. vim reads them just fine. I'm drawing a blank on things I can't do with .gz'd files... I also mention (in bash) foobar (zcat somefile.gz) This works for many cases where the tool needs a file rather than input on standard input. There may be some restrictions (it may not work if the tool needs random access (like gcc)). -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: Deleting uncompressed Info/Doc files at upgrades
On Thursday 15 October 1998, at 17 h 31, the keyboard of Michael Stone [EMAIL PROTECTED] wrote: Hmm. We have zless to less gz'd files. Magicfilter will print them, as will a2ps (maybe some others will too, haven't tried it.) Netscape reads ... will grep them. vim reads them just fine. I'm drawing a blank on things I can't do with .gz'd files... emacs glimpse (don't tell me about .glimpse_filters, it's awfully slow) mutt -a (if the recipient does not have gzip, for instance a regular MacOS or MS-Windows user. The problem is probably the same for all MUA.) agrep (an approximative grep) And this is just what I use often. Do you mean that *every* application in Debian should be patched to read *.gz files?
Re: Deleting uncompressed Info/Doc files at upgrades
On Fri, Oct 16, 1998 at 08:51:45AM +0200, Stephane Bortzmeyer wrote: emacs M-x toggle-auto-compression M-x auto-compression-mode depending on your Emacs. Somebody will probably know how to put this into a .emacs. My Elisp is quite ... rusty. Antti-Juhani -- Antti-Juhani Kaijanaho A7 [EMAIL PROTECTED] ** URL:http://www.iki.fi/gaia/ ** 118. Editing is a rewording activity. (Epigrams on Programming, Alan J. Perlis)
Re: Deleting uncompressed Info/Doc files at upgrades
On Thu, Oct 15, 1998 at 05:31:10PM -0400, Michael Stone wrote: snip Hmm. We have zless to less gz'd files. zless nothing, a simple lesspipe.sh works great, for bigger stuff a not so simple lesspipe.sh (Can give a real complete one if you want, its what I use) works GREAT... Gives file listings for .tar's, handles .bz2 and .gz compression on a file transparently, gives nice readouts for .deb's and .rpm's, renders groffs (man pages), and transparently handles uuencoded files (under .uxx, .uux, and .uue) And its designed in such a way that something like less foo.tar.gz.uue.bz2.uue.gz works perfectly.. (=:] /plug Zephaniah E, Hull. snip Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpgkvyccXUou.pgp Description: PGP signature
Re: Deleting uncompressed Info/Doc files at upgrades
I wrote: It occurs to me that upgrading a package should delete old versions of user-uncompressed doc and info files. Santiago Vila wrote: The package system is not supposed to read your mind. You should never uncompress files in place because then dpkg will be unable to remove the files which belong to a certain package when it is removed or replace by a new one. I wrote back: But... That was my point! Uncompressing docs or info is *not* unusual, nor should it be frowned upon. We should accommodate the possibility of that happening. The same way that a properly-configured Emacs will read-in a compressed file correctly, dpkg should treat an uncompressed file as the same and upgrade it. Craig Sanders wrote: no tool will ever be smart enough to cope perfectly with users leaving crud all over the disk. users should uncompress their files to /tmp or under /usr/local or some other more suitable location. if they choose to do otherwise, then they should accept the consequences of their actions and deal with it themselves. So, at least Craig Sanders and Santiago Vila are so engrained into Debian that they now think the original usable file is the gzip'ed one, not the author's original text. I disagree. Sure, dealing with uncompressed files on upgrade is a special case. Sure dpkg should have to be changed, or maybe /var/lib/dpkg/info/*.list file could have regular expressions, like: /usr/info/emacs-e20-2(.gz)? Mike Stone wrote: Hmm. We have zless to less gz'd files. You see, I didn't even know about that program! Magicfilter will print them, as will a2ps (maybe some others will too, haven't tried it.) Netscape reads them, so does lynx. And of course man and info work with them. zgrep will grep them. vim reads them just fine. I'm drawing a blank on things I can't do with .gz'd files... - A new user won't know about special setups needed for emacs, less and other program. - When I switched to Debian, I used ghostview and not gv for postscript (out of luck there too). - A new user may need the docs on a crippled system, or on a system with only the base system installed. - If you are using some docs often on a 486, you end up uncompressing them because it's too slow otherwise. I'm not arguing that dpkg should handle .aux files files behind after someone has latex'ed docs. I'm arguing that the `intent' of packaging a compressed file is to have the uncompressed original available on the system. Debian upgrades should therefore acknowledge the possibility that files have been decompressed. -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
Re: Deleting uncompressed Info/Doc files at upgrades
Hi, Peter == Peter S Galbraith [EMAIL PROTECTED] writes: Peter So, at least Craig Sanders and Santiago Vila are so engrained Peter into Debian that they now think the original usable file is Peter the gzip'ed one, not the author's original text. I disagree. Count me in with Criag and Santiago. dpkg should never, ever, think it is smarter than the user. It has control over certain files on my disk; it should never touch anything else not in its jurisdiction. There is no reason ever to uncompress a file (lesspipe and lessopen make it unnecessary). When I uncomress a file, it is done for a reason, and dpkg had bloody well leave it alone. Peter - A new user won't know about special setups needed for emacs, less and Peterother program. This should be fixed. The default lessopen script does indeed set it up so. Peter - A new user may need the docs on a crippled system, or on a Petersystem with only the base system installed. The base system has gunzip et al. Peter - If you are using some docs often on a 486, you end up Peteruncompressing them because it's too slow otherwise. In your particular case. Older machines also tend to be tight on disk space, and my 486 is still fast enough to use gunzip on the fly. Peter I'm not arguing that dpkg should handle .aux files files Peter behind after someone has latex'ed docs. I'm arguing that the Peter `intent' of packaging a compressed file is to have the Peter uncompressed original available on the system. Debian Peter upgrades should therefore acknowledge the possibility that Peter files have been decompressed. I disagree quite strongly. If the intent was to have uncompressed originals on the system we would have shipped them as such. manoj -- Bush has it backwards -- abortion is surgical; bombing is murder. sign at anti-war march Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Deleting uncompressed Info/Doc files at upgrades
Manoj Srivastava wrote: There is no reason ever to uncompress a file (lesspipe and lessopen make it unnecessary). Good thing if lesspipe is now correctly setup (Wasn't in bo, and I'm not sure I don't have a older hacked version of /etc/csh.login on my system). You still get garbage if you use more. Perhaps Emacs could use some good defaults too? The base system has gunzip et al. less too? (It's standard, but not required) Peter I'm not arguing that dpkg should handle .aux files files Peter behind after someone has latex'ed docs. I'm arguing that the Peter `intent' of packaging a compressed file is to have the Peter uncompressed original available on the system. Debian Peter upgrades should therefore acknowledge the possibility that Peter files have been decompressed. I disagree quite strongly. If the intent was to have uncompressed originals on the system we would have shipped them as such. Man... Change the sentence to: I'm arguing that the `intent' of packaging a compressed file is to have the uncompressed original INFORMATION available on the system (WHETHER YOU LET LESS TO DO THAT FOR YOU, OR USE GZIP ON THE FILE ITSELF). A uncompressed file is more useful than a compressed one, except that it uses up more space. If dpkg were to upgrade a file that you had uncompressed: - It would not be reading your mind. That's ridiculous. - It would be doing you a favour. - It would be doing the right thing. Why would you possibly _not_ want to upgrade it? I hope I have convinced a few people. I am sure I'm never going to convince Manoj, and I'd rather not argue this forever. -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
Re: Deleting uncompressed Info/Doc files at upgrades
Hi, Peter == Peter S Galbraith [EMAIL PROTECTED] writes: Peter - It would not be reading your mind. That's ridiculous. It would be exceeding its authority. Peter - It would be doing you a favour. Oh no. If I wanted that file upgraded, I would have left it in plcae. Peter - It would be doing the right thing. Why would you possibly Peter_not_ want to upgrade it? Because if I wanted it upgraded, I would have left dpkg have control. By renaming it (which s waht has been done) I move it out of dpkg's hands and into manual control. I surely have reasons to do this. You don't know what the reasons are, and yet you clainm the code knows better and should remove the file? In fasct, unless it can read my mind and figure out that I do want the file removed, you dpkg should keep its grubby little fingers off that file which it kenneth not aboot. Anyway, I think this has been thrashed out enough. If the dpkg authors ever want to change the behaviour, and are sure that the stability of the system shall not be degraded, I shall not voice an objection, no matter how strong my inclination to demurr. manoj -- Q: How many mathematicians does it take to screw in a lightbulb? A: One. He gives it to six Californians, thereby reducing the problem to the earlier joke. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Deleting uncompressed Info/Doc files at upgrades
Quoting Manoj Srivastava ([EMAIL PROTECTED]): This should be fixed. The default lessopen script does indeed set it up so. ?. Less doesn't decode gz's on any of my systems. Mike Stone
Re: Deleting uncompressed Info/Doc files at upgrades
On Friday 2 October 1998, at 11 h 55, the keyboard of Peter S Galbraith [EMAIL PROTECTED] wrote: To me, a uncompressed version of a file is still the same file. To me, copying an uncompressed info file to /usr/local/info *is* leaving crud all over the disk. Yes, the current Debian system is really inconvenient. Each time you want to do something useful with a documentation (print it, grep it, glimpse it, vi it, remember that not every program is able to read compressed files and zcat file.gz | program is not always the simplest thing to do), you have to copy it to an /usr/local. If the purpose of compressing documenattion was to save disk space, this failed! We have now the compressed and the uncompressed version on the disk. And it does not follow the principle of least surprise, judging by the number of beginners (including myself) who had the surprise reported by Peter. In the mean time, as a packager, I prefer to leave documentation uncompressed. Sure, it's a special case. Sure dpkg should have to be changed, or maybe /var/lib/dpkg/info/*.list file could have regular expressions, like: /usr/info/emacs-e20-2(.gz)? It seems a good idea and it will work with bzip2 as well.
Re: Deleting uncompressed Info/Doc files at upgrades
Quoting Stephane Bortzmeyer ([EMAIL PROTECTED]): Yes, the current Debian system is really inconvenient. Each time you want to do something useful with a documentation (print it, grep it, glimpse it, vi it, remember that not every program is able to read compressed files and zcat file.gz | program is not always the simplest thing to do), you have to copy it to an /usr/local. If the purpose of compressing documenattion was to save disk space, this failed! We have now the compressed and the uncompressed version on the disk. Hmm. We have zless to less gz'd files. Magicfilter will print them, as will a2ps (maybe some others will too, haven't tried it.) Netscape reads them, so does lynx. And of course man and info work with them. zgrep will grep them. vim reads them just fine. I'm drawing a blank on things I can't do with .gz'd files... Mike Stone
