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
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
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,
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
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
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,
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)
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
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
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
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
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.
--
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
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
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
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
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
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
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
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
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 #
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
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:
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
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
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
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.
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
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
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
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
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
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 ...
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
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
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.
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
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
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
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
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
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
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 ...
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
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.
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
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
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
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
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
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
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
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
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?
54 matches
Mail list logo
