Re: Using GNU's install-info in Debian instead of dpkg's install-info
Ian Zimmerman writes (Re: Using GNU's install-info in Debian instead of dpkg's install-info): One more thing: the longer this thread gets, the more I think that the original bug is in fact the inclusion of i-i in dpkg. I'm afraid I have to disagree with you there. There is nothing wrong with dpkg containing these relatively small utilities, and adding more Essential packages (often with complex version-depebndent cross-dependencies which are difficult to express) just complicates matters. dpkg is a large and crucially important package, and that means the maintainers always have something more urgent to do than fixing i-i. We should move it into the info package and make the postinstall code conditional on info being installed. There is no particular reason why the people in charge of install-info would have to be blocked by the maintainers of the rest of the dpkg package. Lots of ways of organising this are possible that don't depend on a package split. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Ian Z dpkg is a large and crucially important package, and that means Ian Z the maintainers always have something more urgent to do than Ian Z fixing i-i. We should move it into the info package and make the Ian Z postinstall code conditional on info being installed. Ian J There is no particular reason why the people in charge of Ian J install-info would have to be blocked by the maintainers of the Ian J rest of the dpkg package. Lots of ways of organising this are Ian J possible that don't depend on a package split. This was my hypothesis. That bugs in install-info were not getting fixed or even responded to is a fact. Also, even if division of labour is possible without splitting the package, getting fixes in an actual version in testing will be difficult due to the special status of dpkg. This one I know from past problems with alternatives handling. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Date: Fri, 26 May 2006 18:33:18 -0500 From: [EMAIL PROTECTED] (Karl Berry) Cc: debian-dpkg@lists.debian.org, bug-texinfo@gnu.org Well, the manual changes I personally make are typically fixing packages which install themselves wrongly, so a separate part of the file wouldn't help. However, I may be unusual in bothering to do such things If you are unusual, it makes two of us ;-) I doubt we need to worry overmuch about manual editing. Yes, but IMHO we should worry a little bit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
From: Ian Zimmerman [EMAIL PROTECTED] Date: Fri, 26 May 2006 18:12:02 -0700 (PDT) Cc: debian-dpkg@lists.debian.org, [EMAIL PROTECTED], bug-texinfo@gnu.org Karl I wouldn't expect resource consumption to be the problem. The Karl problem I see is breaking a new install of package X because of Karl something that has happened with package Y or some administrator's Karl action, possibly many years ago. Requiring this sort of perfect Karl consistency of the past to install a package in the present seems Karl fundamentally wrong to me, and a frustration for users and Karl administrators, not a help. What consintency is required? As far as I can see, packages' info files are completely independent. They are _almost_ independent. The small amount of dependency stems from the fact that each Info file specifies the section where it wants to live in DIR. In fact it is the _present_ way that poses this problem, if package X screws up the dirfile format, Y will not find its section correctly (not that it won't happen for other reasons, as I tried to explain before). Karl suggested to make this regeneration of the whole DIR menu as an optional behavior. Wouldn't this let us have the cake and eat it, too? Karl I don't understand. An info file says to install itself in Karl section XYZ. So install-info installs it in section XYZ. What's Karl broken about that? And what name can be used besides the one the Karl info file says, anyway? How do you __find__ the section in the dirfile? You must use some awful regular expression search to find the spot, which is prone to false positives and false negatives. And then you must cut up the dirfile and paste the new bit in. The code doesn't use any regular expressions, it uses exact text comparison (strcmp and the like). It also doesn't cut or paste the file. Please take a look at the code. In a nutshell, the program reads the entire DIR file into memory, builds the data structure that reflects what's in the menu (i.e. all the sections and the menu items found in each section), then sorts each section alphabetically and adds the new entries in the right place in each section specified in the Info file or the command line. Then it produces a new DIR file from the data structure built in memory. All of the bugs that I mention, that motivate me in this debate, and that would motivate me to work on an implementation, spring from this broken process. There are _many many many_. Really. I cited three I had to report 2 weeks ago or so. I had reported 2 or 3 other before. And there were many I didn't even bother to report, preferring like you to hand edit the file in impotent rage. Well, maybe we should see a sample of those bugs to decide how big is the problem and how radical should the solution be. It's possible, at least in theory, that those bugs are relevant only to the way the Debian version of install-info works, and don't happen with the GNU version. Then again, they might be common bugs. Karl Anyway, I really hope Debian I-I and GNU I-I can be merged in the Karl ways Norbert was originally proposing (are you even seeing this Karl mail any more, Norbert?), even if the whole world can't be fixed Karl at the same time. You see, this is why I was disappointed when the discussion turned in the direction of the merge; I sensed (earlier than most people in the thread, I think) that the unification goal and the fixing goal are, all things considered, incompatible. FWIW, I don't see any show-stoppers for now, nothing that a bunch of options cannot resolve. If we have options that leave everybody happy, we should be able to merge, don't you think? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Eli The code doesn't use any regular expressions, it uses exact text Eli comparison (strcmp and the like). It must take account of the context in some way: section names can appear elsewhere in the dir file. I am not saying that this problem is unsolvable in theory. I am saying that it is so error prone that bugs will always be present, and the annoyance factor of the bugs is very high if there's no global regeneration. Eli In a nutshell, the program reads the entire DIR file into memory, Eli builds the data structure that reflects what's in the menu Eli (i.e. all the sections and the menu items found in each section), Eli then sorts each section alphabetically and adds the new entries in Eli the right place in each section specified in the Info file or the Eli command line. Then it produces a new DIR file from the data Eli structure built in memory. Well, this is both better and worse than I thought. Better, because no slicing, but worse, because parsing the whole file amplifies the parsing problem. Eli FWIW, I don't see any show-stoppers for now, nothing that a bunch Eli of options cannot resolve. If we have options that leave everybody Eli happy, we should be able to merge, don't you think? I'd be happy with an option that regenerates the dirfile from the info files. Would the GNU side accept such an option? -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Norbert But if we want this, do we need a merge at all??? Norbert Couldn't Debian write something like update-info-dir and Norbert dh_installinfo does in fact nothing besides putting the info Norbert files into the right directory and adds a call to Norbert update-info-dir to the postinst script. Norbert THe funtion update-info-dir would kill the current dir file, Norbert and call GNU install-info for every info file present. This way Norbert we would be sure that nobody messes up the dir file. And if, Norbert then it was GNU I-I. Sigh. Nobody seems to read my posts or at least understand what I mean. Except Ian Jackson :-) This would not solve the broken parsing problem. Norbert Disadvantage - we have to get rid of this regexp option - Which presently doesn't seem to work at all. Try it. Look at the bugs I cited up in the thread. By numbers. Norbert rebuild of all packages using info files? Yes, transition is the only nontrivial part (apart from politics). Ian left it as an exercise for the reader, and it's a damn hard one. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
On Sam, 27 Mai 2006, Ian Zimmerman wrote: Norbert THe funtion update-info-dir would kill the current dir file, Norbert and call GNU install-info for every info file present. This way Norbert we would be sure that nobody messes up the dir file. And if, Norbert then it was GNU I-I. Sigh. Nobody seems to read my posts or at least understand what I mean. Except Ian Jackson :-) This would not solve the broken parsing problem. Well, no and yes. It would solve the problem of the messed DIR file, as we recreate it always from scratch. And if there is a problem it is house made by us, or GNU i-i. If you speak about the parsing of info files (but you dind't as far as I see), then yes, if an info file is messed up, then we are in trouble. But this should also be handled by GNU i-i. So I don't see where the problem of parsing the DIR file comes in? Ok, assume someone has messed up our info file. Call update-info-dir and the messed up file is gone, forever, recreated. I think I must have missed something. I go and read Debian install-info bugs ;-) Norbert Disadvantage - we have to get rid of this regexp option - Which presently doesn't seem to work at all. Try it. Look at the bugs I cited up in the thread. By numbers. Even better. Let's get rid of it. Norbert rebuild of all packages using info files? Yes, transition is the only nontrivial part (apart from politics). Ian left it as an exercise for the reader, and it's a damn hard one. ;-) Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PUDSEY (n.) The curious-shaped flat wads of dough left on a kitchen table after someone has been cutting scones out of it. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Norbert update-info-dir would kill the current dir file, and call GNU Norbert install-info for every info file present. This way we would be Norbert sure that nobody messes up the dir file. And if, then it was Norbert GNU I-I. Ian This would not solve the broken parsing problem. Norbert Well, no and yes. It would solve the problem of the messed DIR Norbert file, as we recreate it always from scratch. And if there is a Norbert problem it is house made by us, or GNU i-i. Norbert So I don't see where the problem of parsing the DIR file comes Norbert in? Ok, assume someone has messed up our info file. Call Norbert update-info-dir and the messed up file is gone, forever, Norbert recreated. It comes in because that's what GNU i-i does to find the section. I want to avoid it completely, be it in Debian or in GNU. If GNU wants to keep the existing way and make the new way active dependent on an option, that's fine for me. But the new code path should not intersect with the old. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Cc: Ian Zimmerman [EMAIL PROTECTED], [EMAIL PROTECTED], debian-dpkg@lists.debian.org, bug-texinfo@gnu.org From: Ian Zimmerman [EMAIL PROTECTED] Date: Sat, 27 May 2006 06:59:15 -0700 (PDT) Eli The code doesn't use any regular expressions, it uses exact text Eli comparison (strcmp and the like). It must take account of the context in some way: section names can appear elsewhere in the dir file. It uses the context defined by the Info format: a menu starts with the \n* Menu: header, a menu item starts with a \n* if the line isn't a menu header, a section name starts with a \n if the line isn't one of the above. I am not saying that this problem is unsolvable in theory. I am saying that it is so error prone that bugs will always be present, and the annoyance factor of the bugs is very high if there's no global regeneration. If the DIR file is invalid as far as the Info format is concerned, then yes, the code might eventually fail. But other than that, it is not prone to bugs that regular expressions are prone to: i.e., it will never catch any context except precisely as specified above. Eli In a nutshell, the program reads the entire DIR file into memory, Eli builds the data structure that reflects what's in the menu Eli (i.e. all the sections and the menu items found in each section), Eli then sorts each section alphabetically and adds the new entries in Eli the right place in each section specified in the Info file or the Eli command line. Then it produces a new DIR file from the data Eli structure built in memory. Well, this is both better and worse than I thought. Better, because no slicing, but worse, because parsing the whole file amplifies the parsing problem. Only if the file is invalid, I think. For such cases, there are some safety nets in the code, although I'm sure they can be improved. I'd be happy with an option that regenerates the dirfile from the info files. Would the GNU side accept such an option? I think Karl already suggested precisely that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
On Sam, 27 Mai 2006, Ian Zimmerman wrote: Norbert So I don't see where the problem of parsing the DIR file comes Norbert in? Ok, assume someone has messed up our info file. Call Norbert update-info-dir and the messed up file is gone, forever, Norbert recreated. It comes in because that's what GNU i-i does to find the section. I want to avoid it completely, be it in Debian or in GNU. If GNU Ok, but at least we cannot say that a messed up DIR file makes a problem. The only problem is the parsing algorithm in GNU i-i. What happens if someone puts the Section text somewhere else. But I assume that one can fix the GNU i-i versions parsing that the section search algorithm does not find the description of an entry. wants to keep the existing way and make the new way active dependent on an option, that's fine for me. But the new code path should not intersect with the old. The new code-path would be - parse the info file and extract the section - write the info into some sort of config file into a to be specified directory. - After this read all the config files and generate a dir file from it. Right? Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- GOLANT (adj.) Blank, sly and faintly embarrassed. Pertaining to the expression seen on the face of someone who has clearly forgotten your name. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Hi all! On Sam, 27 Mai 2006, Eli Zaretskii wrote: If the DIR file is invalid as far as the Info format is concerned, then yes, the code might eventually fail. But other than that, it is not prone to bugs that regular expressions are prone to: i.e., it will never catch any context except precisely as specified above. But wouldn't this make it definitely possible to regenerate the dir file from all the info files, as I suggested. The only thing we have to make sure is that the parsing dues not get something wrong *IN A FILE THAT WE ARE CURRRENTLY CREATING*. So the onyl thing is that GNUi-i created correct dir files, which I assume. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- BURBAGE The sound made by a liftful of people all trying to breathe politely through their noses. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Norbert But I assume that one can fix the GNU i-i versions parsing that Norbert the section search algorithm does not find the description of Norbert an entry. As I wrote in my conversation with Eli: yes, in theory. In practice, having lived with this way of doing things for a few years (albeit in Debian i-i, not GNU), I am doubtful that the problems can be eliminated. Ian wants to keep the existing way and make the new way active dependent Ian on an option, that's fine for me. But the new code path should not Ian intersect with the old. Norbert The new code-path would be Norbert - parse the info file and extract the section Norbert - write the info into some sort of config file into a to be specified Norbert directory. This step is optional. The info files themselves can serve as the config repository, although then there's the additional step of deciding which are the top ones holding the metadata. Norbert - After this read all the config files and generate a dir file from it. Yes. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
One more thing: the longer this thread gets, the more I think that the original bug is in fact the inclusion of i-i in dpkg. dpkg is a large and crucially important package, and that means the maintainers always have something more urgent to do than fixing i-i. We should move it into the info package and make the postinstall code conditional on info being installed. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Hi Ian! On Sam, 27 Mai 2006, Ian Zimmerman wrote: One more thing: the longer this thread gets, the more I think that the original bug is in fact the inclusion of i-i in dpkg. Yup. dpkg is a large and crucially important package, and that means the maintainers always have something more urgent to do than fixing i-i. We This is something I understand. should move it into the info package and make the postinstall code conditional on info being installed. Or create a new package install-info? This was suggested before, together with an adjustment of Priority. BUT: It is ok if we move this here, but I am not the principal author of the Debian i-i, and I cannot do much about it than package it. Solutions to this mess from my side can come only by getting a differnet approach, ie doing the creating stuff inside GNU i-i. Anyway, how do we proceed? Move it into a new package in texinfo? And who will care for the bugs ;-) Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- POLLOCH (n.) One of those tiny ribbed-plastic and aluminium foil tubs of milk served on trains enabling you to carry one safely back to you compartment where your legs in comfort trying to get the bloody things open. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Norbert Or create a new package install-info? This was suggested Norbert before, together with an adjustment of Priority. Norbert BUT: It is ok if we move this here, but I am not the principal Norbert author of the Debian i-i, and I cannot do much about it than Norbert package it. Solutions to this mess from my side can come only Norbert by getting a differnet approach, ie doing the creating stuff Norbert inside GNU i-i. Norbert Anyway, how do we proceed? Move it into a new package in texinfo? And ^^^ ? Norbert who will care for the bugs ;-) I can take the responsibility for having the regeneration code included in GNU i-i, in coordination with the GNU people. As I am not a Debian member, perhaps you can best take it from there. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
On Sam, 27 Mai 2006, Ian Zimmerman wrote: I can take the responsibility for having the regeneration code included in GNU i-i, in coordination with the GNU people. As I am not a Debian member, perhaps you can best take it from there. Perfect with me, really. If you manage to implement the option (see my other email) than I guess Karl would also be happy to get some help in install-info. The rest we will care for. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MALIBU (n.) The height by which the top of a wave exceeds the height to which you have rolled up your trousers. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Right. I have a hard time waiting for the merge to complete. Well, we're closer to a merge than at any time in the last 10 years or so (since whenever Debian install-info came into existence), so there is some cause for hope :). Good question, and easy to answer with a simple script, at least relative to the packages I have installed. I'll do that within a few days. Great, thanks. Everything necessary for the installation of a menu entry. I guess it's all within INFO-DIR-ENTRY, isn't it? As far as I can think of, but ... It wouldn't be visible to end users, and packages would interact with it through a narrow interface (ie. the revamped install-info). In my experience, it is *useful* for people to be able to edit the dir file. I don't think we should make it harder to do so, by only allowing changes through some other file and a regeneration process. I don't see that we gain anything critical by it. I like the idea of being able to regenerate the dir file from installed info files much more. And in fact the Texinfo distribution includes several scripts (fix-info-dir, gen-dir-node, maybe others) to do just that. None of them ever seemed to be installable quality. If that can be added to install-info (yikes) or one or another of the scripts made more robust so it could be a standard installed program, that would be great. Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Karl I like the idea of being able to regenerate the dir file from Karl installed info files much more. And in fact the Texinfo Karl distribution includes several scripts (fix-info-dir, gen-dir-node, Karl maybe others) to do just that. None of them ever seemed to be Karl installable quality. If that can be added to install-info Karl (yikes) or one or another of the scripts made more robust so it Karl could be a standard installed program, that would be great. But, for me to consider it a solution, it would have to be run by packages in their post-installs, which means manual edits would be overwritten. Maybe another idea: keep a part of the file explicitly reserved for manual additions, delimit it with some markers. Anything outside is fair game for packages. There is precedent for this in Debian, e.g. the handling of xorg.conf. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
But, for me to consider it a solution, it would have to be run by packages in their post-installs, which means manual edits would be overwritten. Am I understanding right? You want `make install' for every package to regenerate the dir node from scratch, based on *every installed info file*? I hope not ... My assumption was that install-info would continue to just read INFO-DIR-SECTION from the given file and install the given dir entries in the given sections, and not try to look at any other info file. That's what it (the GNU version) does now, and this seems right to me. Maybe I'm not understanding what Debian install-info does. Maybe another idea: keep a part of the file explicitly reserved for manual additions, delimit it with some markers. Well, the manual changes I personally make are typically fixing packages which install themselves wrongly, so a separate part of the file wouldn't help. However, I may be unusual in bothering to do such things, and it's not critical in my life to support it. I doubt we need to worry overmuch about manual editing. Thanks, karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Ian But, for me to consider it a solution, it would have to be run by Ian packages in their post-installs, which means manual edits would be Ian overwritten. Karl Am I understanding right? You want `make install' for every Karl package to regenerate the dir node from scratch, based on *every Karl installed info file*? I hope not ... Yes, that is precisely what I am proposing. According to Joey Hess (you do see the whole thread, right?) it isn't too time consuming. And it relects what Debian does for other things, like menus. Karl My assumption was that install-info would continue to just read Karl INFO-DIR-SECTION from the given file and install the given dir Karl entries in the given sections, and not try to look at any other ^^ Karl info file. That's what it (the GNU version) does now, and this Karl seems right to me. The highlighted part is the catch - you're keeping the broken parsing. Ian Maybe another idea: keep a part of the file explicitly reserved for Ian manual additions, delimit it with some markers. Karl Well, the manual changes I personally make are typically fixing Karl packages which install themselves wrongly, so a separate part of Karl the file wouldn't help. Isn't that need exactly what we're trying to eliminate? -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
According to Joey Hess (you do see the whole thread, right?) Apparently not. I didn't see that mail, anyway. it isn't too time consuming. I wouldn't expect resource consumption to be the problem. The problem I see is breaking a new install of package X because of something that has happened with package Y or some administrator's action, possibly many years ago. Requiring this sort of perfect consistency of the past to install a package in the present seems fundamentally wrong to me, and a frustration for users and administrators, not a help. If you want to require it for Debian, that's fine, of course, and it can be an option or whatever in I-I. I can imagine many people would like it. But, at least in the form I'm envisioning, I don't think it should be the default for GNU. And it relects what Debian does for other things, like menus. Sorry, I don't know what menus you're referring to. The highlighted part is the catch - you're keeping the broken parsing. I don't understand. An info file says to install itself in section XYZ. So install-info installs it in section XYZ. What's broken about that? And what name can be used besides the one the info file says, anyway? I'm sure you know all this, so now I feel completely lost. Isn't that need exactly what we're trying to eliminate? As far as I can see, the way to eliminate manual fixes is to fix the source Texinfo files in the first place (to use consistent section names, formatting, etc.), which in fact I have spent a lot of effort on. The situation is better than it used to be, although of course it's very far from perfect. Anyway, I really hope Debian I-I and GNU I-I can be merged in the ways Norbert was originally proposing (are you even seeing this mail any more, Norbert?), even if the whole world can't be fixed at the same time. Thanks, karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Karl I wouldn't expect resource consumption to be the problem. The Karl problem I see is breaking a new install of package X because of Karl something that has happened with package Y or some administrator's Karl action, possibly many years ago. Requiring this sort of perfect Karl consistency of the past to install a package in the present seems Karl fundamentally wrong to me, and a frustration for users and Karl administrators, not a help. What consintency is required? As far as I can see, packages' info files are completely independent. In fact it is the _present_ way that poses this problem, if package X screws up the dirfile format, Y will not find its section correctly (not that it won't happen for other reasons, as I tried to explain before). Karl If you want to require it for Debian, that's fine, of course, and Karl it can be an option or whatever in I-I. I can imagine many people Karl would like it. But, at least in the form I'm envisioning, I don't Karl think it should be the default for GNU. Ian And it relects what Debian does for other things, like menus. This should of course be reflects, sorry for that. I should really learn to use the spellchecker :-( Karl Sorry, I don't know what menus you're referring to. All of them. Debian has a unified system for updating global menus based on information in packages. Window manager or desktop menus, HTML documentation directories, others that I don't know of. Each package installs a little configuration file and, at post-install time, regenerates the whole menu from all packages' bits (including its own). Ian The highlighted part is the catch - you're keeping the broken Ian parsing. Karl I don't understand. An info file says to install itself in Karl section XYZ. So install-info installs it in section XYZ. What's Karl broken about that? And what name can be used besides the one the Karl info file says, anyway? How do you __find__ the section in the dirfile? You must use some awful regular expression search to find the spot, which is prone to false positives and false negatives. And then you must cut up the dirfile and paste the new bit in. All of the bugs that I mention, that motivate me in this debate, and that would motivate me to work on an implementation, spring from this broken process. There are _many many many_. Really. I cited three I had to report 2 weeks ago or so. I had reported 2 or 3 other before. And there were many I didn't even bother to report, preferring like you to hand edit the file in impotent rage. Karl Anyway, I really hope Debian I-I and GNU I-I can be merged in the Karl ways Norbert was originally proposing (are you even seeing this Karl mail any more, Norbert?), even if the whole world can't be fixed Karl at the same time. You see, this is why I was disappointed when the discussion turned in the direction of the merge; I sensed (earlier than most people in the thread, I think) that the unification goal and the fixing goal are, all things considered, incompatible. (All things means different GNU cultural traditions, personalities, etc.) -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Ian Zimmerman wrote: It's wrong on two counts: 1/ The visual format of the dir file is used for collecting the sections. This has all the robustness of, say, grepping for text in a Postscript file. 2/ Since no record is kept of the individual additions by packages, there's no way to recreate the dir file from scratch. So, if a package does screw up (often due to 1 above), all one can do is manually edit the dirfile. This happens maddeningly often, at least to me: see #367255, #367254, #367251. I agree, there's also all the fun of bugs in packages that have to deal with the current complex install-info. (Anyone want to fix #337215 or #357434 for me?) There are two proper fixes. One is in the realm of policy: require every info file passed to install-info to contain the full metadata, including INFO-DIR-SECTION. Then we can dispense with the --section option completely and 1 magically goes away, while 2 is solved by rescanning the metadata in the top-level installed files (as Joey suggests in the other thread). The other way is to keep some kind of simple database on the side which install-info first updates, then uses to generate the dirfile. dpkg is a required package, so if install-info stays in dpkg the database library must also be required. I thought of asking the Perl maintainer to move the venerable Data::Dumper module into perl-base, that would be enough for me. My experience with using Data::Dumper for long-term data storage is abysmal, it's on the order of dumping C structs to disk. However, my benchmarks of parsing /usr/share/info/*.info* for all the metadata I think install-info should need to use the first method suggests it can be done without perceivable delay on any modern machine (and even reasonably quickly on my less than modern one). When I discussed this IRL at DebConf, one problem raised is that this still leaves Debian w/o an install-info that behaves like GNU expects, so we still have the portability problems we have now. I wonder if there's any way to provide an install-info that ignores most/all parameters and manages to be effectively compatible with programs expecting the GNU or Debian install-infos while still avoiding parsing the info dir file. -- see shy jo signature.asc Description: Digital signature
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Guillem Jover wrote: The nice property of this one, is that then we can conditionally call install-info on maintainer scripts, and make the new package where install-info is going to be move to, non-essential (after a transition phase). I'd go for this one. It also allows for competing install-info implementations in Debian, to explore all kinds of interesting[1] ways to better organise and lay out the info dir file. -- see shy jo [1] If anyone still finds info interesting. ;-) signature.asc Description: Digital signature
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Ian Zimmerman writes (Re: Using GNU's install-info in Debian instead of dpkg's install-info): It's wrong on two counts: 1/ The visual format of the dir file is used for collecting the sections. This has all the robustness of, say, grepping for text in a Postscript file. 2/ Since no record is kept of the individual additions by packages, Just for the record as the original designer and implementer of the dpkg install-info I agree completely with what Ian Zimmerman says there. If I had to do it again I would do it very differently. The other way is to keep some kind of simple database on the side which install-info first updates, then uses to generate the dirfile. The right answer is to do it the way the menu system does it: packages install the info metadata as part of their static contents, in /usr/share somewhere, and then their postinsts run a script to regenerate /info/dir from the contents. When dpkg has hooks (aka triggers) then this can be used instead of the postinst rune. Transition from here to there is left as an exercise to the reader (although some careful thought is necessary as history suggests that this kind of thing is often screwed up ...) Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Karl Hi Ian, (Did you bcc me? I doubt I am on debian-dpkg :) No, according to my records I To'd you :-) Ian For everyone here, the main problem seem to be the Debian vs. GNU Ian fork. But for me, the main problem is the bugs. Karl Well, resolving the fork will presumably only help with being able Karl to then address the bugs to benefit the most people. Right. I have a hard time waiting for the merge to complete. Ian require every info file passed to install-info to contain the full Ian metadata, including INFO-DIR-SECTION. Karl Sounds good, in theory. Karl In practice, how many currently-installed info files lack Karl INFO-DIR-SECTION? Good question, and easy to answer with a simple script, at least relative to the packages I have installed. I'll do that within a few days. Karl What else do you think we should require? Everything necessary for the installation of a menu entry. I guess it's all within INFO-DIR-ENTRY, isn't it? Ian The other way is to keep some kind of simple database on the side Ian which install-info first updates Karl Adding another database which has to be kept in sync (and which Karl inevitably will go out of sync and then has to be recovered from) Karl seems like more trouble to me, not less. The idea is that it wouldn't be another one, but _the_ authoritative one from which the visually formatted infodir file could always be re-derived. It wouldn't be visible to end users, and packages would interact with it through a narrow interface (ie. the revamped install-info). So the chance of it going somehow bad would be much, much smaller than with the visible dir file. Karl Can you include bug-texinfo@gnu.org (and whatever on the Debian Karl side) in future mail? Sure, and also including myself because Mail-Copies-To doesn't seem to be operative on the list. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
I wanted to help with this, see the parallel thread at http://lists.debian.org/debian-dpkg/2006/05/msg00063.html but unfortunately I see it's moving in a different direction than I intended. For everyone here, the main problem seem to be the Debian vs. GNU fork. But for me, the main problem is the bugs. And as I see it, while the merge might fix some of the particular bugs known right now, the potential for many more remains, and eventually they'll come charging back, because the algorithm is wrong. It's wrong on two counts: 1/ The visual format of the dir file is used for collecting the sections. This has all the robustness of, say, grepping for text in a Postscript file. 2/ Since no record is kept of the individual additions by packages, there's no way to recreate the dir file from scratch. So, if a package does screw up (often due to 1 above), all one can do is manually edit the dirfile. This happens maddeningly often, at least to me: see #367255, #367254, #367251. There are two proper fixes. One is in the realm of policy: require every info file passed to install-info to contain the full metadata, including INFO-DIR-SECTION. Then we can dispense with the --section option completely and 1 magically goes away, while 2 is solved by rescanning the metadata in the top-level installed files (as Joey suggests in the other thread). The other way is to keep some kind of simple database on the side which install-info first updates, then uses to generate the dirfile. dpkg is a required package, so if install-info stays in dpkg the database library must also be required. I thought of asking the Perl maintainer to move the venerable Data::Dumper module into perl-base, that would be enough for me. -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
On Tue, 2006-05-23 at 20:14:32 -0700, Ian Zimmerman wrote: It's wrong on two counts: 1/ The visual format of the dir file is used for collecting the sections. This has all the robustness of, say, grepping for text in a Postscript file. 2/ Since no record is kept of the individual additions by packages, there's no way to recreate the dir file from scratch. So, if a package does screw up (often due to 1 above), all one can do is manually edit the dirfile. This happens maddeningly often, at least to me: see #367255, #367254, #367251. There are two proper fixes. One is in the realm of policy: require every info file passed to install-info to contain the full metadata, including INFO-DIR-SECTION. Then we can dispense with the --section option completely and 1 magically goes away, while 2 is solved by rescanning the metadata in the top-level installed files (as Joey suggests in the other thread). The nice property of this one, is that then we can conditionally call install-info on maintainer scripts, and make the new package where install-info is going to be move to, non-essential (after a transition phase). I'd go for this one. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Hello, Just to keep you informed, as every one seems to agree on using the GNU instal-info in Debian, the plan (discussed a little bit at DebConf) is to first patch install-info to support the dpkg's install-info options: i.e. mostly the --section and maybe --remove-exactly (maybe the behavior of the GNU --remove is sufficient; this has to be checked with the emacs packages). For the --section option, the GNU's i-i has one argument, and dpkg's one takes two arguments. This will probably be the way we can detect whether we want the GNU's or dpkg's behavior. I intent to make the patch, but won't be connected until the end of the month, so if somebody wants to do it, please do. What I think has to be done for --section is: * detect if there are 2 arguments to the --section option * detect if this second argument is a file (install-info --section section info-file dir-file is a GNU install-info command line, it should not be taken as a dpkg command line: install-info --section regex section info-file) Of course if a file exists with the same name as the section, this algorithm doesn't work. But it doesn't seems to happen according to my dir file. On Fri, May 19, 2006 at 09:53:23AM +0200, [EMAIL PROTECTED] wrote: Of course! How do we come to a conclusion on this topic? I think it is up to the dpkg developer to decide. AFAIU, they agree. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Hi Karl! On Son, 21 Mai 2006, Nicolas François wrote: I intent to make the patch, but won't be connected until the end of the month, so if somebody wants to do it, please do. I take a look, but I have a conference at the end of the month, so my time is limited ... What I think has to be done for --section is: * detect if there are 2 arguments to the --section option * detect if this second argument is a file (install-info --section section info-file dir-file is a GNU install-info command line, it should not be taken as a dpkg command line: install-info --section regex section info-file) Of course if a file exists with the same name as the section, this algorithm doesn't work. But it doesn't seems to happen according to my dir file. Karl, what do you think. Would this be acceptable to be merged into install-info? Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- AFFCOT (n.) The sort of fart you hope people will talk after. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Hi, On Sun, May 21, 2006 at 07:50:22PM +0200, Norbert Preining wrote: Hi Karl! On Son, 21 Mai 2006, Nicolas François wrote: What I think has to be done for --section is: * detect if there are 2 arguments to the --section option * detect if this second argument is a file (install-info --section section info-file dir-file is a GNU install-info command line, it should not be taken as a dpkg command line: install-info --section regex section info-file) Of course if a file exists with the same name as the section, this algorithm doesn't work. But it doesn't seems to happen according to my dir file. Karl, what do you think. Would this be acceptable to be merged into install-info? Maybe the change in Debian will have to be temporary (i.e. provide support for the current behavior of dpkg's i-i for a few (Debian) releases) Supporting multiple arguments for an option in getopt is not really clean and having an option which accepts either one or two arguments is maybe not very clean either (I mean for upstream) (moreover, i-i accepts a variable number of parameters at the ends). Maybe we can make a wrapper in Debian (something like the attached script) that will pass the first argument of the --section option to a new --section-regex option. i.e. change install-info --section regex section info-file to ginstall-info --section-regex regex --section section info-file Maybe Karl will be interested by the --section-regex option. (It permits to install the info file in a section that match this regex and is not necessarily exactly the same as specified with --section; the section specified with --section is still used if no sections match the regex) Kind Regards, -- Nekral install-info.sh Description: Bourne shell script
Re: Using GNU's install-info in Debian instead of dpkg's install-info
Hi all! On Son, 21 Mai 2006, Nicolas François wrote: * detect if there are 2 arguments to the --section option * detect if this second argument is a file (install-info --section section info-file dir-file is a GNU install-info command line, it should not be taken as a dpkg command line: install-info --section regex section info-file) Of course if a file exists with the same name as the section, this algorithm doesn't work. But it doesn't seems to happen according to my dir file. Karl, what do you think. Would this be acceptable to be merged into install-info? Maybe the change in Debian will have to be temporary (i.e. provide support for the current behavior of dpkg's i-i for a few (Debian) releases) Supporting multiple arguments for an option in getopt is not really clean and having an option which accepts either one or two arguments is maybe not very clean either (I mean for upstream) (moreover, i-i accepts a variable number of parameters at the ends). It also seemed to me that hacking this into upstream would not work out, so I asked Karl. If we can add the --section-regex argument which would be clean and useful for upstream, too, we continue as planned before, moving ginstall-info and the wrapper script into a new package. Maybe we can make a wrapper in Debian (something like the attached script) that will pass the first argument of the --section option to a new --section-regex option. i.e. change I will save it away for now. And implementing the --sectin-regex seems to be a bit easier than checking for 1 vs 2 argumetns. I see only one problem: AFAIR the GNU install-info has to be minimal and cannot rely on (many) other things. But here Karl should tell us more, what the conditions are. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- THRUMSTRER (n.) The irritating man next to you in a concert who thinks he's (a) the conductor, (b) the brass section. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
* detect if there are 2 arguments to the --section option Sounds fine to me. It is also ok (preferable) to have --section-regex; of course that's a lot cleaner, so if that works out ok for Debian, great. You-all know a lot better than me. The prospect of merging Debian i-i into GNU i-i is wonderful. In general, I'm not going to be finicky about the details. Thanks, karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using GNU's install-info in Debian instead of dpkg's install-info
I see only one problem: AFAIR the GNU install-info has to be minimal and cannot rely on (many) other things. Yes, GNU I-I can't rely on much of anything else. Probably best for it to stay a C program. As I understand it, the wrapper would be in debian only, not gnu. Works for me. Probably nicer than the optional-number-of-arguments-in-getopt stuff. Thanks, k -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
