Re: dpkg / apt equivalent to 'rpm -qf'?
Kevin Mark [EMAIL PROTECTED] schrieb: On Tue, Aug 24, 2004 at 06:00:47PM +0200, Frank Küster wrote: John Hasler [EMAIL PROTECTED] wrote: ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? How should a package tell dpkg to install an empty file, if it needs that? Regards, Frank Hi Frank, man touch Which does not help in this context. The question was: How can files that are (perhaps) created by maintainer scripts be registered to dpkg?, and one answer was: By including them in the deb as empty files. But this would have the consequence that all those files would have to be created by dpkg, and clutter /etc. I had understood from John's question that he wanted dpkg just to ignore empty files, except that it registers them for the package. But this would make it impossible for a package to ship an empty file. Indeed, it could create it in a maintainer script, but that's plain rubbish - change dpkg to do illogical things, and then work around this in maintainer scripts. Better find an other way to register those files (there have been proposals). Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler wrote: Thomas Adam writes: ...But removing the symlinks in /etc/rc?.d/* for whatever DM is running... If you remove them they will be recreated when you upgrade the package. Sysvconfig allows you to disable stuff. Just select Enable/Disable in the main menu and follow directions. Oh dear!! Dolphin:~# sysvconfig --listlinks Couldn't open rc0.d/: No such file or directory Dolphin:~# ls /etc/rc?.d Had me going for a moment. I use file-rc. Echidna:~# apt-get install sysvconfig Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package sysvconfig Echidna:~# That's Woody. Okay, I do have a Sarge box without file-rc. Looks promising. Now it needs to get part of the base install _and_ mentioned in the relevant manuals:-) For other RH (and SuSE) refuges it the package basically duplicates the functionality of the chkconfig and service commands. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler wrote: I wrote: Just off the top of my head I see no reason why these files [created by maintainer scripts] could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. Thomas Adam writes: The overhead in doing this is stupid... A few dozen bytes in each of those few packages that need it, less any reduction in the postinst and postrm. ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? In rpm, they're typically not empty - they're full of interesting and useful comments, and potentially usable defaults. :-) -- Paul http://paulgear.webhop.net -- Did you know? If you use two dashes followed by a space as your signature separator, good email programs will chop them off automatically, reducing noise in email replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Paul Gear writes: In rpm, they're typically not empty - they're full of interesting and useful comments, and potentially usable defaults. We are talking about files the contents of which are created by maintainer scripts. Other configuration files in Debian packages _are_ full of interesting and useful comments and potentially usable defaults. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler wrote: Paul Gear writes: In rpm, they're typically not empty - they're full of interesting and useful comments, and potentially usable defaults. We are talking about files the contents of which are created by maintainer scripts. Other configuration files in Debian packages _are_ full of interesting and useful comments and potentially usable defaults. shrug In all my years using Red Hat Linux I never heard of such a thing. I don't understand why it should be necessary. I know shorewall 2.0 as packaged for Debian has an empty /etc/shorewall, but why it shouldn't be full of sample config files containing lots of interesting comments I really don't know. Or even better maybe, four shorewall packages - the current one being renamed shorewall-common and the others each depending on shorewall-common and having sample configurations for one interface, two (common gateway) three (like two but with DMZ). this is not a comment directed at Shorewalll so much as I've picked a package with which I'm familiar, and which comes without config files it will need. Iven where the developer finds it absolutely necessary to generate config files at install time, I don't see why there can't be (maybe empty, maybe entirely commented out) config files to replace. Apache has, for years, had empty config files with no more than comments saying, Don't use this file. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Frank Küster writes: But this would have the consequence that all those files would have to be created by dpkg, and clutter /etc. No files would be created that were not subsequently filled in by a maintainer script. I don't know where you get the idea that that any files, empty or otherwise, would be created that are not created now. I had understood from John's question that he wanted dpkg just to ignore empty files, except that it registers them for the package. You misunderstood. ...change dpkg... I proposed no changes whatsoever to dpkg. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sysvconfig was: dpkg / apt equivalent to 'rpm -qf'?
John Summerfield writes: I use file-rc. I didn't think that people who know about file-rc and choose to install it would be interested in sysvconfig (note the name). Patches are welcome. Now it needs to get part of the base install... I see little chance of that. For other RH (and SuSE) refuges it the package basically duplicates the functionality of the chkconfig and service commands. That is who the package is primarily intended for. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Paul Gear writes: ...when i come to a config file that is important to the running of a package, i expect that there should be some way to trace it back to the fact that relates to the package. Please read the thread from the beginning. That is precisely what we are talking about. Evidently there is a proposal to solve this problem by changing dpkg to make it possible to register files. Perhaps we'll see some action on this someday. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Wed, Aug 25, 2004 at 08:33:47AM -0500, John Hasler wrote: Frank Küster writes: But this would have the consequence that all those files would have to be created by dpkg, and clutter /etc. No files would be created that were not subsequently filled in by a maintainer script. I don't know where you get the idea that that any files, empty or otherwise, would be created that are not created now. I had understood from John's question that he wanted dpkg just to ignore empty files, except that it registers them for the package. You misunderstood. ...change dpkg... I proposed no changes whatsoever to dpkg. What were you planning to do on upgrade? Normally, dpkg would set the files back to empty. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler [EMAIL PROTECTED] schrieb: Frank Küster writes: But this would have the consequence that all those files would have to be created by dpkg, and clutter /etc. No files would be created that were not subsequently filled in by a maintainer script. I don't know where you get the idea that that any files, empty or otherwise, would be created that are not created now. There are maintainer scripts that create different configuration files, or a different number of configuration files, depending on the existing settings on the installing computer - or depending on debconf answers. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dpkg / apt equivalent to 'rpm -qf'?
John Summerfield writes: I know shorewall 2.0 as packaged for Debian has an empty /etc/shorewall, but why it shouldn't be full of sample config files containing lots of interesting comments I really don't know. Because you have not filed a bug with a patch containing such a file. Even where the developer finds it absolutely necessary to generate config files at install time, I don't see why there can't be (maybe empty, maybe entirely commented out) config files to replace. That's exactly what I was suggesting. However, I see no point in putting anything in a file that is going to be overwritten at installation. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Frank Küster writes: There are maintainer scripts that create different configuration files, or a different number of configuration files, depending on the existing settings on the installing computer - or depending on debconf answers. Those scripts could remove the files they don't use. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Colin Watson writes: What were you planning to do on upgrade? Normally, dpkg would set the files back to empty. And the postinst will fill them up again (the preinst could save them, but that's ugly). There is no point in discussing this further, though, if dpkg is going to have a registration scheme. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler wrote: John Summerfield writes: I know shorewall 2.0 as packaged for Debian has an empty /etc/shorewall, but why it shouldn't be full of sample config files containing lots of interesting comments I really don't know. Because you have not filed a bug with a patch containing such a file. Don't be silly. It was a deliberate decision by the maintainer. The config files are present, they're in the doc directory. If I proffered a patch, it would almost certainly be declined. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler [u] wrote on 25/08/2004 17:23: Frank Küster writes: There are maintainer scripts that create different configuration files, or a different number of configuration files, depending on the existing settings on the installing computer - or depending on debconf answers. Those scripts could remove the files they don't use. Oh well, and if a debian user would create those files anew (but uses them for a different thing), dpkg would happily remove them when a package which could create them is removed or purged. No thanks ;-) Also, there are a few scripts around which check wether the files on a system still match those in the installed packages, which would fail on these, too. I think the only way is to really create a way for maintainer scripts to (de)register files with dpkg on the fly. Ideally, this could be a registration for files that are removed when the package is removed or files that are removed on purge only. cu, sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Wed, Aug 25, 2004 at 09:14:53PM +0800, John Summerfield wrote: John Hasler wrote: Or even better maybe, four shorewall packages - the current one being renamed shorewall-common and the others each depending on shorewall-common and having sample configurations for one interface, two (common gateway) three (like two but with DMZ). Huh? there are three shorewall packages shorewall shorewall-doc webmin-shorewall At any rate, the splitting up of packages is done for a variety of good reasons. Maybe you want the client and not the server. Maybe many other packages can get away with dependencies on foo-common, rather than all of foo. There lots of reasons why debian packagers do this and it usually is for good reason, not the least of which is courtesy to you, the user. this is not a comment directed at Shorewalll so much as I've picked a package with which I'm familiar, and which comes without config files it will need. What's the problem is they are in /usr/share/doc/package/examples? It seems to me a perfectly sane way to do things. That's the standard place packagers put these things, especially configurations for packages like shorewall, which could completely break your system (or make it inaccessible) if incorrect, so leaving it out altogether makes pretty sure you aren't going to start it misconfigured. Debian makes extensive use of /usr/share/doc, so one really should look there for answers first. Speaking of which, as for splitting up packages, you might check the changelog.Debian.gz in the packages doc folder. The reason will probably be in there somewhere. -- _ _ _ _ _ _ _ _ _ _ _ _ _ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ ( t | i | m | @ | i | t | . | k | p | t | . | c | c ) \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ GPG key fingerprint = 1DEE CD9B 4808 F608 FBBF DC21 2807 D7D3 09CA 85BF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Tim Kelley quotes: On Wed, Aug 25, 2004 at 09:14:53PM +0800, John Summerfield wrote: John Hasler wrote: Or even better maybe, four shorewall packages - the current one being renamed shorewall-common and the others each depending on shorewall-common and having sample configurations for one interface, two (common gateway) three (like two but with DMZ). Just to clarify, I did not write that. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Tim Kelley wrote: On Wed, Aug 25, 2004 at 09:14:53PM +0800, John Summerfield wrote: John Hasler wrote: Or even better maybe, four shorewall packages - the current one being renamed shorewall-common and the others each depending on shorewall-common and having sample configurations for one interface, two (common gateway) three (like two but with DMZ). Huh? there are three shorewall packages shorewall shorewall-doc webmin-shorewall Not really: the last is a component of webmin. The second should be able to be installed independently of shorewall: it's reasonable to install -doc on my workstation without shorewall, and shorewall provides the functionality. At any rate, the splitting up of packages is done for a variety of good reasons. Maybe you want the client and not the server. Maybe many other packages can get away with dependencies on foo-common, rather than all of foo. There lots of reasons why debian packagers do this and it usually is for good reason, not the least of which is courtesy to you, the user. this is not a comment directed at Shorewalll so much as I've picked a package with which I'm familiar, and which comes without config files it will need. What's the problem is they are in /usr/share/doc/package/examples? It seems to me a perfectly sane way to do things. The way it's done is they're not config files and that is all my point is. Were they in /etc/shorewall then they would be identifiable config files That's the standard place packagers put these things, especially configurations for packages like shorewall, which could completely break your system (or make it inaccessible) if incorrect, so leaving it out altogether makes pretty sure you aren't going to start it misconfigured. Debian makes extensive use of /usr/share/doc, so one really should look there for answers first. Speaking of which, as for splitting up packages, you might check the changelog.Debian.gz in the packages doc folder. The reason will probably be in there somewhere. I really do not care. It is irrelevant to the conext of _this_ thread. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler wrote: Tim Kelley quotes: On Wed, Aug 25, 2004 at 09:14:53PM +0800, John Summerfield wrote: John Hasler wrote: Or even better maybe, four shorewall packages - the current one being renamed shorewall-common and the others each depending on shorewall-common and having sample configurations for one interface, two (common gateway) three (like two but with DMZ). Just to clarify, I did not write that. No, I did. I did so to illustrate how an arbitrary product could be packages with identifiable config using existing debian packaging technology. Despite Tim's misinterpretation, it was a comment on packaging and not on shorewall: shorewall is simply the first example that came to mind of a package that requires config files but has none. I suggested those different packages (which are basically config files) because those reflect models described on the shortwall website. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Thu, Aug 26, 2004 at 06:17:49AM +1000, Paul Gear wrote: John Hasler wrote: That is precisely what we are talking about. What you said was We are talking about files the contents of which are created by maintainer scripts. My point was that it doesn't matter what creates it (the package or the maintainer script), it's counter-intuitive that you can't track back from a file to its related application. If the package creates it (i.e., it's shipped in the .deb), then 'dpkg -S' will tell you about it; so you and John are in fact talking about exactly the same thing. John is just drilling down and trying to work out ways of implementing it. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpkg / apt equivalent to 'rpm -qf'?
Hi folks, What is the canonical method for determining to which package an installed file belongs? dpkg -S seems to be the right *sort* of thing, but doesn't always work: enoch:/share/download # dpkg -S /etc/apt/apt.conf.d/70debconf debconf: /etc/apt/apt.conf.d/70debconf enoch:/share/download # dpkg -S /etc/apt/sources.list dpkg: /etc/apt/sources.list not found. enoch:/share/download # dpkg -S /etc/gpm.conf dpkg: /etc/gpm.conf not found. -- Paul http://paulgear.webhop.net -- Did you know? Most email-borne viruses use a false sender address. Therefore you cannot track down the sender using that address. Instead, keep your virus scanning software up-to-date and just delete any suspicious emails you receive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 09:44:33PM +1000, Paul Gear wrote: Hi folks, What is the canonical method for determining to which package an installed file belongs? dpkg -S seems to be the right *sort* of thing, but doesn't always work: enoch:/share/download # dpkg -S /etc/apt/apt.conf.d/70debconf debconf: /etc/apt/apt.conf.d/70debconf enoch:/share/download # dpkg -S /etc/apt/sources.list dpkg: /etc/apt/sources.list not found. enoch:/share/download # dpkg -S /etc/gpm.conf dpkg: /etc/gpm.conf not found. It's doing *exactly* what you asked of it. Remember that dpkg -S will only work for files that were *in* a package initially and not ones that were *created*. /etc/apt/sources.list is created by apt-setup from 'base-config', but does not reside in any package. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Hello Paul Gear ([EMAIL PROTECTED]) wrote: What is the canonical method for determining to which package an installed file belongs? dpkg -S seems to be the right *sort* of thing, but doesn't always work: enoch:/share/download # dpkg -S /etc/apt/apt.conf.d/70debconf debconf: /etc/apt/apt.conf.d/70debconf enoch:/share/download # dpkg -S /etc/apt/sources.list dpkg: /etc/apt/sources.list not found. enoch:/share/download # dpkg -S /etc/gpm.conf dpkg: /etc/gpm.conf not found. Sometimes files are not part of the packages, but are created after installation. Take a look at /var/lib/dkpg/info/apt.list and /var/lib/dpkg/info/apt.postinst. I don't know if there is an eays way to find these files, apart from grepping /var/lib/dpkg/info. best regards Andreas Janssen -- Andreas Janssen [EMAIL PROTECTED] PGP-Key-ID: 0xDC801674 ICQ #17079270 Registered Linux User #267976 http://www.andreas-janssen.de/debian-tipps.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam wrote: On Tue, Aug 24, 2004 at 09:44:33PM +1000, Paul Gear wrote: Hi folks, What is the canonical method for determining to which package an installed file belongs? dpkg -S seems to be the right *sort* of thing, but doesn't always work: enoch:/share/download # dpkg -S /etc/apt/apt.conf.d/70debconf debconf: /etc/apt/apt.conf.d/70debconf enoch:/share/download # dpkg -S /etc/apt/sources.list dpkg: /etc/apt/sources.list not found. enoch:/share/download # dpkg -S /etc/gpm.conf dpkg: /etc/gpm.conf not found. It's doing *exactly* what you asked of it. Remember that dpkg -S will only work for files that were *in* a package initially and not ones that were *created*. /etc/apt/sources.list is created by apt-setup from 'base-config', but does not reside in any package. Is it fairly common, then, that packages only create their config files, and don't include them in the package originally. I can see times when that would lead to confusion. Is there another way to find out where a file belongs? (I am resigned to the rest of this message being flame bait, even though it's not intended that way.) RPM's method of including the config file in the package even if it's empty or only comments seems to me a better solution - that way the config file can always be traced back to its relevant package. -- Paul http://paulgear.webhop.net -- If at first you *do* succeed, carefully check your success metrics for accuracy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 01:11:33PM +0100, Thomas Adam wrote: It's doing *exactly* what you asked of it. Remember that dpkg -S will only work for files that were *in* a package initially and not ones that were *created*. /etc/apt/sources.list is created by apt-setup from 'base-config', but does not reside in any package. Geez. Try answering the question, not insulting the guy. The dpkg man page is unclear on what -S does: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. So, is there a dpkg option that allows one to determine from which package a file came? Or, is there some other program that can provide this information? Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 10:28:09PM +1000, Paul Gear wrote: Is it fairly common, then, that packages only create their config files, and don't include them in the package originally. I can see times when Of course it is. There are *hundreds* of files that are created in this manner, usually brought about because they're created by the very programs in other packages, and so there is no way of ever supplying the files in the first place. that would lead to confusion. Is there another way to find out where a file belongs? No, since any answer would be completely erroneous. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: Geez. Try answering the question, not insulting the guy. The dpkg man page is unclear on what -S does: I wasn't insulting anybody. The *words* were there, only to place emphasis on the fundamental differences in operation. dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? So, is there a dpkg option that allows one to determine from which package a file came? Or, is there some other program that can provide this information? dpkg -S is only ever useful if you want to check to see whether a file comes from a package installed on your system. As I have said, if the file was created by an application, then it clearly cannot belong to a package. No information is retained to the creating program, other than *possibly* debconf's database. If you want to search for files in packages that you do not have installed, then apt-file is your friend. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam writes: As I have said, if the file was created by an application, then it clearly cannot belong to a package. The question was about files created by the maintainer scripts. Just off the top of my head I see no reason why these files could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 08:23:16AM -0500, John Hasler wrote: Thomas Adam writes: As I have said, if the file was created by an application, then it clearly cannot belong to a package. The question was about files created by the maintainer scripts. Was it now? I don't believe so, although files created by maintainer scripts is one aspect to the question. But the answer will still be the same. I'm not sure how many times I have to re-iterate it, but: If a file is created by an application, then the file will not be part of any package, unless the file in question was already part of the package. Just off the top of my head I see no reason why these files could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. The overhead in doing this is stupid, and having a lot of empty files in /etc is just pointless. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 09:24:45AM -0400, Carl Fink wrote: On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. They're not from any package -- they're created by programs that are themselves from packages. But how on Earth can you keep information as to programs that created files? It's a stupid and pointless exercise. Please see my other posts as to the explanations why. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Jason Rennie wrote: ... Geez. Try answering the question, not insulting the guy. Don't worry - i'm used to it on this list by now... :-) -- Paul http://paulgear.webhop.net -- Did you know? Email addresses can be forged easily. This message is signed with GNU Privacy Guard http://www.gnupg.org and Enigmail http://enigmail.mozdev.org so you can be sure it comes from me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam wrote: On Tue, Aug 24, 2004 at 09:24:45AM -0400, Carl Fink wrote: On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. They're not from any package -- they're created by programs that are themselves from packages. But how on Earth can you keep information as to programs that created files? It's a stupid and pointless exercise. Please see my other posts as to the explanations why. Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: # to list configuration files [EMAIL PROTECTED]:~ rpm -qc glibc-2.3.2-120 /etc/nscd.conf /etc/rpc #to find what owns a configuration file: [EMAIL PROTECTED]:~ rpm -qf /etc/defaultdomain netcfg-9.0-7 [EMAIL PROTECTED]:~ To find what documentation might pertain to the configuration file: [EMAIL PROTECTED]:~ rpm -qdf /etc/defaultdomain [EMAIL PROTECTED]:~ Bad example, there is none in that package. This is better: [EMAIL PROTECTED]:~ rpm -qf /usr/share/man/man8/rpcinfo.8.gz glibc-2.3.2-120 [EMAIL PROTECTED]:~ rpm -qfd /usr/share/man/man8/rpcinfo.8.gz /usr/share/doc/packages/glibc/LICENSES /usr/share/man/man1/getconf.1.gz /usr/share/man/man1/getent.1.gz /usr/share/man/man1/glibcbug.1.gz /usr/share/man/man1/iconv.1.gz /usr/share/man/man1/ldd.1.gz /usr/share/man/man1/locale.1.gz /usr/share/man/man1/localedef.1.gz /usr/share/man/man5/locale.alias.5.gz /usr/share/man/man5/nscd.conf.5.gz /usr/share/man/man8/ldconfig.8.gz /usr/share/man/man8/nscd.8.gz /usr/share/man/man8/nscd_nischeck.8.gz /usr/share/man/man8/rpcinfo.8.gz [EMAIL PROTECTED]:~ The above is on SuSE. In contrast, my Debian system has /etc/defaultdomain but no man page: SuSE's man page is in another package. I would expect every file in /etc on the SuSE (or a Red Hat) system to be owned by a package, unless I created it. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, 24 Aug 2004, Thomas Adam wrote: On Tue, Aug 24, 2004 at 10:28:09PM +1000, Paul Gear wrote: Is it fairly common, then, that packages only create their config files, and don't include them in the package originally. I can see times when Of course it is. There are *hundreds* of files that are created in this manner, usually brought about because they're created by the very programs in other packages, and so there is no way of ever supplying the files in the first place. Or by debconf-ization of packages, which often need this. that would lead to confusion. Is there another way to find out where a file belongs? No, since any answer would be completely erroneous. Actually, we have been requesting this functionality to the dpkg crew for a while. It will arrive someday. The idea is that we will register dynamically-created stuff with a package in the maintainer script. But right now, all you can do if you *really* need to find out where a package came from is to use dpkg -L, and when that fails, try to grep for that filename in /var/lib/dpkg/info, which might or might not help. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, 24 Aug 2004, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:23:16AM -0500, John Hasler wrote: Just off the top of my head I see no reason why these files could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. The overhead in doing this is stupid, and having a lot of empty files in /etc is just pointless. But we could be doing that if it worked. It doesn't. Hint: empty files, as well as missing files, are valid states of a conffile and dpkg would act accordingly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler writes: Just off the top of my head I see no reason why these files could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. I think the canonical answer is that some programs will behave differently if a config file exists (even if empty) than if it doesn't exist. E.g., /etc/nologin -- you wouldn't want to ship that :-) Then there are some files that it's questionable who they would belong to. For instance, /etc/ld.so.conf needs to be modified by several packages; if it was owned by some package, it would be a Policy violation for any other package to touch it. Then someone would have to write an update-ld.so.conf script, which just seems like overkill. I agree that the vast majority of postinst-created files in /etc don't meet either of these criteria, so the suggestion makes sense there. My understanding is that there is long-term work planned on dpkg to allow registering a list of related files on package installation, even if they aren't actually in the package. -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 11:33:09AM -0300, Henrique de Moraes Holschuh wrote: On Tue, 24 Aug 2004, Thomas Adam wrote: On Tue, Aug 24, 2004 at 10:28:09PM +1000, Paul Gear wrote: Is it fairly common, then, that packages only create their config files, and don't include them in the package originally. I can see times when Of course it is. There are *hundreds* of files that are created in this manner, usually brought about because they're created by the very programs in other packages, and so there is no way of ever supplying the files in the first place. Or by debconf-ization of packages, which often need this. Yes, I mentioned that. that would lead to confusion. Is there another way to find out where a file belongs? No, since any answer would be completely erroneous. Actually, we have been requesting this functionality to the dpkg crew for a while. It will arrive someday. Right. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com Why just use our trusty old friend find? also you have locate, whereis, and a bunch of others, I must say find can do about anything. Also whereis is a nice catch all for common files and programs. It seems that you need to use the right tool for the job, and frankly I don't see dpkg -S as a good solution. It works for packages that dpkg knows about. But then that could be said of the same for rpm -qf. Rthoreau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 09:22:16AM -0500, Rthoreau wrote: Why just use our trusty old friend find? Because the question is Which package was responsible for creating this conffile? How can find answer that? -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
I wrote: Just off the top of my head I see no reason why these files [created by maintainer scripts] could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. Thomas Adam writes: The overhead in doing this is stupid... A few dozen bytes in each of those few packages that need it, less any reduction in the postinst and postrm. ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Henrique de Moraes Holschuh writes: Actually, we have been requesting this functionality to the dpkg crew for a while. It will arrive someday. The idea is that we will register dynamically-created stuff with a package in the maintainer script. That's a good solution. It deals with the possibility that files might be conditionally created. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Rthoreau writes: Why just use our trusty old friend find? also you have locate, whereis, and a bunch of others, I must say find can do about anything. How do you propose to get find to tell you which files were created by a particular package, or which package created a particular file? File names often have no obvious connection to the package that created them. It seems that you need to use the right tool for the job, and frankly I don't see dpkg -S as a good solution. It works for packages that dpkg knows about. The subject is files created by packages installed by dpkg. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam [EMAIL PROTECTED] writes: On Tue, Aug 24, 2004 at 09:24:45AM -0400, Carl Fink wrote: On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. They're not from any package -- they're created by programs that are themselves from packages. Are configuration files that cannot be associated with exactly one package all that common? I would have thought that most configuration files that are not in a package are created (and removed) by the maintainer scripts of exactly one package. In this case, it would certainly (IMHO) make sense to have a way by which the name of the package can be queried. For the user, the mechanism which has created the file may be less important than the information which package is responsible for the file. But how on Earth can you keep information as to programs that created files? One possibility would be that the maintainer script which creates the file stores the filename in something like /var/lib/dpkg/info/PACKAGE.createdfiles. It's a stupid and pointless exercise. I don't agree. Martin -- ,--. ,= ,-_-. =. / ,- )Martin Dickopp, Dresden, Germany((_/)o o(\_)) \ `-'http://www.zero-based.org/`-'(. .)`-' `-. \_/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Martin writes: One possibility would be that the maintainer script which creates the file stores the filename in something like /var/lib/dpkg/info/PACKAGE.createdfiles. Gaak! No! The archive must _only_ be accessed via the packaging system tools. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler [EMAIL PROTECTED] wrote: ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? How should a package tell dpkg to install an empty file, if it needs that? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 10:18:08PM +0800, John Summerfield wrote: Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: Yes, so how exactly, for example, is phpmyadmin supposed to touch files, such as httpd.conf, so that it works and is properly configured *when it is installed*? Hmm? If httpd.conf was owned by apache, no other package could touch it (I think we all agree allowing this would be a mess), how can it modify the file to allow itself to work? The is why some configuration files are created upon installation and not owned by any package. So we have a tradeoff. I prefer having to do a little hunting to figure out which package created the file than, as on a SuSE or Red Hat system, have completely misconfigured software all over the system. You ignore the fact that almost all red hat packages, when installed, are broken. I think that is a far bigger problem. You are forgetting that Debian has taken the packaging system far, far beyond anything Red Hat or SuSE have done. -- _ _ _ _ _ _ _ _ _ _ _ _ _ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ ( t | i | m | @ | i | t | . | k | p | t | . | c | c ) \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ GPG key fingerprint = 1DEE CD9B 4808 F608 FBBF DC21 2807 D7D3 09CA 85BF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler [EMAIL PROTECTED] writes: Martin writes: One possibility would be that the maintainer script which creates the file stores the filename in something like /var/lib/dpkg/info/PACKAGE.createdfiles. Gaak! No! The archive must _only_ be accessed via the packaging system tools. I didn't mean to imply otherwise. In this scenario, the maintainer scripts would modify the .createdfiles file through packaging system tools. Come to think of it, the .createdfiles file could even be a static part of the package. If it contains a list of all files the maintainer scripts /potentially/ create, it wouldn't need to be modified at all. Even if /var/lib/dpkg/info is not the right place, my point still stands that it would technically feasible to maintain such a list of created files for each package. :) Martin -- ,--. ,= ,-_-. =. / ,- )Martin Dickopp, Dresden, Germany((_/)o o(\_)) \ `-'http://www.zero-based.org/`-'(. .)`-' `-. \_/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 11:35:28AM -0500, Tim Kelley wrote: On Tue, Aug 24, 2004 at 10:18:08PM +0800, John Summerfield wrote: Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: Yes, so how exactly, for example, is phpmyadmin supposed to touch files, such as httpd.conf, so that it works and is properly configured *when it is installed*? Hmm? If httpd.conf was owned by apache, no other package could touch it (I think we all agree allowing this would be a mess), how can it modify the file to allow itself to work? The is why some configuration files are created upon installation and not owned by any package. So we have a tradeoff. I prefer having to do a little hunting to figure out which package created the file than, as on a SuSE or Red Hat system, have completely misconfigured software all over the system. You ignore the fact that almost all red hat packages, when installed, are broken. I think that is a far bigger problem. You are forgetting that Debian has taken the packaging system far, far beyond anything Red Hat or SuSE have done. It appears that there are two distinct roles for packages with respect to files: 1 the .deb of the package contains an initial copy of the file 2 the package programs/scripts are permitted/expected to maintain and update the file as needed. It is unually assumed that only one package may play either of these roles with respect to a given file, and that it should be the same package for a given file. But httpd.conf seems to be a counter example for role 2. That only one package may play Role 2 w.r.t. a given file is Debian policy only for files that are served Role 1 by that same package. When the httpd.conf situation arises, the Debian way seems to be that a package constructs an initial copy of the file on the fly, rather than containing an initial copy. Thus, the file is built by the package but not owned by the package. This may sound goofy to outsiders, but it preserves the primacy of policy while solving a practical problem. However, there is a problem waiting for a smart lawyer to exploit: There is nothing in these rules that precludes some arbitrary new package from touching httpd.conf for some purpose of its own that has nothing to do with the proper operation of a web server system. What does keep this from happening is the good sense of Debian maintainers. Until someone can come up with a plausible example of why it might thought reasonable to have some other package, mutt, for example, touch httpd.conf maybe we can avoid adding more rules to policy. But if a new ruled are needed, consider defining groups of packages that own a particular file as tenants in common or as joint tenants. The existence of these groups would have to be documented somehow, and the programs written to maintain the documentation. It sounds like a lot of work for very little gain. -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Tim Kelley wrote: On Tue, Aug 24, 2004 at 10:18:08PM +0800, John Summerfield wrote: Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: Yes, so how exactly, for example, is phpmyadmin supposed to touch files, such as httpd.conf, so that it works and is properly configured *when it is installed*? Hmm? If httpd.conf was owned by apache, no other package could touch it (I think we all agree allowing this would be a mess), how can it modify the file to allow itself to work? The is why some configuration files are created upon installation and not owned by any package. /etc/httpd/conf/conf.d Something workable seems done in Apache2. It wouldn't be hard to build a temp config on the fly in a similar way to how modutils works: concatenatea bunch of partial files to create one single file. A proforma or empty httpd.conf would be shipped. So we have a tradeoff. I prefer having to do a little hunting to figure out which package created the file than, as on a SuSE or Red Hat system, have completely misconfigured software all over the system. You ignore the fact that almost all red hat packages, when installed, are broken. I think that is a far bigger problem. You are forgetting that Debian has taken the packaging system far, far beyond anything Red Hat or SuSE have done. How broken? I agree Debian was once the leader, but I think that's no longer the case. How long since you actually tried RH or SuSE products? I think several aspects of Debian behaviour are ill-conceived: 1. That I want to start a daemon as soon as I've installed it Typically I want to install at the office, configure in the field. 2. That I want to configure software when I install it. Typically I want to read the (gasp) documentation. 3. That if I have KDE|GNOME|whatever DTE installed I always want to run it when I boot. For various reason I sometimes want to boot to an otherwise fully functioning system without gooey stuff. For example, KDE hangs one partituclar system I have if it sees real hardware. Under VNC it's fine. 4. That I know where in the startup/shutdown process each daemon belongs. On RHL SuSE if I decide to turn ptal off because my printeris causing grief, it's a simple command to do so. Later, I can easily turn it back on in its proper place in the startup sequence. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Wed, Aug 25, 2004 at 08:57:42AM +0800, John Summerfield wrote: 1. That I want to start a daemon as soon as I've installed it Typically I want to install at the office, configure in the field. So download the files but don't complete the install until you're in the field. The -d flag to apt-get. 2. That I want to configure software when I install it. Typically I want to read the (gasp) documentation. So skip the configuration step and use dpkg--reconfigure later. 3. That if I have KDE|GNOME|whatever DTE installed I always want to run it when I boot. Okay, that annoys me, too. 4. That I know where in the startup/shutdown process each daemon belongs. On RHL SuSE if I decide to turn ptal off because my printeris causing grief, it's a simple command to do so. Later, I can easily turn it back on in its proper place in the startup sequence. I don't understand this. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Paul E Condon wrote: It appears that there are two distinct roles for packages with respect to files: 1 the .deb of the package contains an initial copy of the file 2 the package programs/scripts are permitted/expected to maintain and update the file as needed. It is unually assumed that only one package may play either of these roles with respect to a given file, and that it should be the same package for a given file. But httpd.conf seems to be a counter example for role 2. That only one package may play Role 2 w.r.t. a given file is Debian policy only for files that are served Role 1 by that same package. When the httpd.conf situation arises, the Debian way seems to be that a package constructs an initial copy of the file on the fly, rather than containing an initial copy. Thus, the file is built by the package but not owned by the package. This may sound goofy to outsiders, but it preserves the primacy of policy while solving a practical problem. However, there is a problem waiting for a smart lawyer to exploit: There is nothing in these rules that precludes some arbitrary new package from touching httpd.conf for some purpose of its own that has nothing to do with the proper operation of a web server system. What does keep this from happening is the good sense of Debian maintainers. Until someone can come up with a plausible example of why it might thought reasonable to have some other package, mutt, for example, touch httpd.conf maybe we can avoid adding more rules to policy. Policy isa fine thing where it facilitates getting the job at hand done. When it gets in the way, then the policy needs review. But if a new ruled are needed, consider defining groups of packages that own a particular file as tenants in common or as joint tenants. The existence of these groups would have to be documented somehow, and the programs written to maintain the documentation. It sounds like a lot of work for very little gain. You will find certain directories owned by an enormous number of packages. In the particular case of Apache, it seems to me there could be a standard httpd.conf with standard optional components defined but perhaps commented out. There could be a standard way of activating those components when an optional module, say webdav, is installed, deactivating them when it's removed. This is not very different from the way inetd.conf works. A separate application, such as pgpgroupware, which requires significant configuration changes to Apache, should (as phpgroupware does) contain its own configuration file. The active httpd.conf needs to be modified to the extent of adding an include statement when the application is to be activated (which, I might add, is _not_ when it's installed!). -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 09:06:50PM -0400, Carl Fink wrote: 3. That if I have KDE|GNOME|whatever DTE installed I always want to run it when I boot. Okay, that annoys me, too. rcconf is quite handy. But removing the symlinks in /etc/rc?.d/* for whatever DM is running, or editing /etc/X11/default-display-manager (again, we've been over this before), is nothing trivial. 4. That I know where in the startup/shutdown process each daemon belongs. On RHL SuSE if I decide to turn ptal off because my printeris causing grief, it's a simple command to do so. Later, I can easily turn it back on in its proper place in the startup sequence. I don't understand this. See rcconf, above. That's possibly what he's getting at. -- Thomas Adam -- Quis custodiet ipsos custodes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam writes: ...But removing the symlinks in /etc/rc?.d/* for whatever DM is running... If you remove them they will be recreated when you upgrade the package. Sysvconfig allows you to disable stuff. Just select Enable/Disable in the main menu and follow directions. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 06:00:47PM +0200, Frank Küster wrote: John Hasler [EMAIL PROTECTED] wrote: ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? How should a package tell dpkg to install an empty file, if it needs that? Regards, Frank Hi Frank, man touch -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... signature.asc Description: Digital signature
