FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 01-03-2010, 10:11 PM
Felipe Sateler
 
Default Conffiles

On Sun, 2010-01-03 at 14:50 -0800, Russ Allbery wrote:
> Felipe Sateler <fsateler@gmail.com> writes:
>
> > Do conffiles have to be regular files? Policy does not seem to be
> > explicit about this (although I'd be happy to be proven wrong on this),
> > it seems to just talk about "files".
>
> I don't believe that listing symlinks as conffiles works properly at the
> moment. See #421344. It doesn't make any sense to list a directory as a
> conffile. I think that exhausts all the non-regular files that can be in
> a Debian package.

Thanks for the quick answer. FWIW, this question comes because
checkinstall currently tags everything as a conffile, which caused dpkg
to fail when directories were tagged.

--
Saludos,
Felipe Sateler



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-03-2010, 10:37 PM
Russ Allbery
 
Default Conffiles

Felipe Sateler <fsateler@gmail.com> writes:

> Thanks for the quick answer. FWIW, this question comes because
> checkinstall currently tags everything as a conffile, which caused dpkg
> to fail when directories were tagged.

Yeah, I don't think it makes sense to tag a directory as a conffile. The
sort of management of a directory implied by the rules for a conffile is
basically done already, automatically, provided that the contents of the
directory are all marked as conffiles or are other directories.

Policy does specifically talk about files, and conventionally directories
are not considered files, but it might be worth adding something
clarifying there. It's also worth saying something about symlinks, so
I'll open a bug on Debian Policy to document that.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2010, 02:41 AM
Manoj Srivastava
 
Default Conffiles

On Sun, Jan 03 2010, Russ Allbery wrote:

> Felipe Sateler <fsateler@gmail.com> writes:
>
>> Do conffiles have to be regular files? Policy does not seem to be
>> explicit about this (although I'd be happy to be proven wrong on this),
>> it seems to just talk about "files".
>
> I don't believe that listing symlinks as conffiles works properly at the
> moment. See #421344. It doesn't make any sense to list a directory as a
> conffile. I think that exhausts all the non-regular files that can be in
> a Debian package.

A conffile is, after all, a configuration file. As such, it
contains configuration data, and user changes to such data is what
policy is concerned about preserving. Merely the presence or absence of
a inode or a link does not rise to the level of "configuration data",
in my view. Why add restrictions on what people can do?

Now, if the target of the symlink is under /etc, then the target
is really the configuration file, if the target does not lie under
/etc, we have a policy violation.

> Symlinks as conffiles should ideally work. I think it's just a bug in
> dpkg that they don't.

While it could be made to work, I am not sure I agree that the
result would require the same protection in policy.

I am willing to be persuaded otherwise on this.

manoj
--
"We all suffer from the preoccupation that there exists ... in the loved
one, perfection." -Sidney Poitier
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2010, 02:57 AM
Russ Allbery
 
Default Conffiles

Manoj Srivastava <srivasta@ieee.org> writes:
> On Sun, Jan 03 2010, Russ Allbery wrote:

>> I don't believe that listing symlinks as conffiles works properly at
>> the moment. See #421344. It doesn't make any sense to list a
>> directory as a conffile. I think that exhausts all the non-regular
>> files that can be in a Debian package.

> A conffile is, after all, a configuration file. As such, it
> contains configuration data, and user changes to such data is what
> policy is concerned about preserving. Merely the presence or absence of
> a inode or a link does not rise to the level of "configuration data",
> in my view. Why add restrictions on what people can do?

I think a symlink created by the package in /etc should be handled like a
conffile in the sense that if the sysadmin changes the symlink to point to
a different path, that's a change that should be preserved. As I recall,
that's the scenario that prompted Bug#421344 originally. Currently, I
believe such changes are not preserved on package upgrade.

> Now, if the target of the symlink is under /etc, then the target
> is really the configuration file, if the target does not lie under
> /etc, we have a policy violation.

Symlinks in /etc pointing to files not in /etc are used now, so I'm not
sure they should be Policy violations. /etc/nologin is the canonical
example. Depending on how and whether Debian adopts upstart, we may have
other cases.

>> Symlinks as conffiles should ideally work. I think it's just a bug in
>> dpkg that they don't.

> While it could be made to work, I am not sure I agree that the
> result would require the same protection in policy.

> I am willing to be persuaded otherwise on this.

Well, I think all that Policy requires for configuration files that would
be relevant to symlinks is:

* If the administrator removes it, it stays removed on package upgrade.

* If the administrator changes it, which in the case of a symlink just
means pointing it to a different path, that change is either preserved
or prompted about.

Both of those seem feasible and reasonable to me. (Of course, someone
would need to do the work, and I don't think it's the highest-priority
dpkg development goal.)

I'm not sure what the implications of changing the symlink to be a real
file or a directory would be. (I'm not sure what happens if an
administrator changes a regular conffile to a directory.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2010, 10:10 AM
Matthew Johnson
 
Default Conffiles

On Sun Jan 03 19:57, Russ Allbery wrote:
> Symlinks in /etc pointing to files not in /etc are used now, so I'm not
> sure they should be Policy violations. /etc/nologin is the canonical
> example. Depending on how and whether Debian adopts upstart, we may have
> other cases.

Shouldn't they be files in /etc pointed to by symlinks not in /etc?

Matt

--
Matthew Johnson
 
Old 01-04-2010, 05:25 PM
Russ Allbery
 
Default Conffiles

Matthew Johnson <mjj29@debian.org> writes:
> On Sun Jan 03 19:57, Russ Allbery wrote:

>> Symlinks in /etc pointing to files not in /etc are used now, so I'm not
>> sure they should be Policy violations. /etc/nologin is the canonical
>> example. Depending on how and whether Debian adopts upstart, we may
>> have other cases.

> Shouldn't they be files in /etc pointed to by symlinks not in /etc?

That's a much more common case, but there are instances, such as with
/etc/nologin, where there are reasons not to do that. (The specific
difficulty with /etc/nologin is that /etc is allowed to be read-only.)

With upstart, packages that only support upstart jobs can support legacy
init systems by shipping a symlink to an upstart helper that supports the
init script syntax instead of an init script. This isn't currently
allowed in Debian due to the required dependencies, but it's one possible
transition path should Debian adopt Ubuntu's upstart system.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-05-2010, 12:33 AM
Manoj Srivastava
 
Default Conffiles

On Sun, Jan 03 2010, Russ Allbery wrote:

> Manoj Srivastava <srivasta@ieee.org> writes:
>> On Sun, Jan 03 2010, Russ Allbery wrote:
>
>>> I don't believe that listing symlinks as conffiles works properly at
>>> the moment. See #421344. It doesn't make any sense to list a
>>> directory as a conffile. I think that exhausts all the non-regular
>>> files that can be in a Debian package.
>
>> A conffile is, after all, a configuration file. As such, it
>> contains configuration data, and user changes to such data is what
>> policy is concerned about preserving. Merely the presence or absence of
>> a inode or a link does not rise to the level of "configuration data",
>> in my view. Why add restrictions on what people can do?
>
> I think a symlink created by the package in /etc should be handled like a
> conffile in the sense that if the sysadmin changes the symlink to point to
> a different path, that's a change that should be preserved. As I recall,
> that's the scenario that prompted Bug#421344 originally. Currently, I
> believe such changes are not preserved on package upgrade.
>
>> Now, if the target of the symlink is under /etc, then the target
>> is really the configuration file, if the target does not lie under
>> /etc, we have a policy violation.
>
> Symlinks in /etc pointing to files not in /etc are used now, so I'm not
> sure they should be Policy violations. /etc/nologin is the canonical
> example. Depending on how and whether Debian adopts upstart, we may have
> other cases.

Hmm. The part that bothers me about this is that I can't just
say $EDITOR /etc/foo-that-is-a-symlink and expect it to work, unless
the symlink points to a file on a fs that is not mounted RO. But I
guess this is not a major obstacle.

I don't like configuration data not all being under /etc; s that
backing up /etc no longer saves a snapshot of my configuration.


>>> Symlinks as conffiles should ideally work. I think it's just a bug in
>>> dpkg that they don't.
>
>> While it could be made to work, I am not sure I agree that the
>> result would require the same protection in policy.
>
>> I am willing to be persuaded otherwise on this.
>
> Well, I think all that Policy requires for configuration files that would
> be relevant to symlinks is:
>
> * If the administrator removes it, it stays removed on package upgrade.
>
> * If the administrator changes it, which in the case of a symlink just
> means pointing it to a different path, that change is either preserved
> or prompted about.

> Both of those seem feasible and reasonable to me. (Of course, someone
> would need to do the work, and I don't think it's the highest-priority
> dpkg development goal.)

If this does not yet work, it does not really belong in policy
yet -- we should let the implementation happen and the design settle
down before standardizing the behaviour.

> I'm not sure what the implications of changing the symlink to be a real
> file or a directory would be. (I'm not sure what happens if an
> administrator changes a regular conffile to a directory.)

Umm, directories can't be conffiles, no? So not considering
directories, if symlinks can be conffiles, and regular files can be
conffiles, I think users should be allowed to change one conffile into
another. And the code must then handle that case.

manoj
--
There are bugs and then there are bugs. And then there are bugs. Karl
Lehenbauer
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-05-2010, 02:07 AM
Russ Allbery
 
Default Conffiles

Manoj Srivastava <srivasta@ieee.org> writes:
> On Sun, Jan 03 2010, Russ Allbery wrote:

>> Symlinks in /etc pointing to files not in /etc are used now, so I'm not
>> sure they should be Policy violations. /etc/nologin is the canonical
>> example. Depending on how and whether Debian adopts upstart, we may
>> have other cases.

> Hmm. The part that bothers me about this is that I can't just
> say $EDITOR /etc/foo-that-is-a-symlink and expect it to work, unless
> the symlink points to a file on a fs that is not mounted RO. But I
> guess this is not a major obstacle.

> I don't like configuration data not all being under /etc; s that
> backing up /etc no longer saves a snapshot of my configuration.

In the case of the possible use case for upstart, the target of the
symlink is the entirety of the configuration in that case, so there's
nothing lost by only backing up /etc. It's either a symlink pointing to
the generic upstart code to do the right thing with an upstart job
(separately installed in /etc/upstart.d or wherever), or it's a file
implementing a more conventional init script.

nologin is a weird special case, but I think the idea is that it's not
persistent configuration anyway. If you're restoring the configuration of
one box to another, chances are you don't want /etc/nologin anyway.

> If this does not yet work, it does not really belong in policy
> yet -- we should let the implementation happen and the design settle
> down before standardizing the behaviour.

Oh, agreed. My proposal for Policy would be to state, for the time being,
that only regular files can be conffiles and that neither symlinks nor
directories (the latter being somewhat obvious, but worth stating
explicitly) can be conffiles.

If at some point symlinks as conffiles are implemented in dpkg, we would
then change Policy. Right now, if one declares a symlink as a conffile,
bad things happen.

> Umm, directories can't be conffiles, no? So not considering
> directories, if symlinks can be conffiles, and regular files can be
> conffiles, I think users should be allowed to change one conffile into
> another. And the code must then handle that case.

Yes, I think that's right. That could probably be handled in a way
similar to the current handling of a deleted conffile.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-05-2010, 02:04 PM
Manoj Srivastava
 
Default Conffiles

On Mon, Jan 04 2010, Russ Allbery wrote:


>> Umm, directories can't be conffiles, no? So not considering
>> directories, if symlinks can be conffiles, and regular files can be
>> conffiles, I think users should be allowed to change one conffile into
>> another. And the code must then handle that case.
>
> Yes, I think that's right. That could probably be handled in a way
> similar to the current handling of a deleted conffile.

The tricky case is if a user replaces a symlink with a copy of
the original target -- no content changes whatsoever. Should the user
be prompted? I can see arguments either way, and certainly the
potential exists for violating the principle of least surprise
whichever take we have on that.

manoj
--
It's later than you think, the joint Russian-American space mission has
already begun.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-31-2011, 03:04 AM
Russ Allbery
 
Default Conffiles

Josh Triplett <josh@joshtriplett.org> writes:
> Enrico Weigelt wrote:

>> I have a general objection against putting (default) configs outside
>> /etc at all. The main problem is, on updates, defaults might silently
>> change, without operators used to look at /etc and comparing current
>> config with new defaults.

> By default, dpkg will silently upgrade unmodified conffiles to the
> current version, without prompting the user at all. If you've modified
> the conffile, dpkg will prompt you to find out if you want to keep your
> modified version, upgrade to the new upstream version, see a diff, or
> run a shell; dpkg will default to keeping your modified version.

> So, unless you've changed a configuration file, you already won't get a
> prompt on configuration upgrades.

But right now with configuration in /etc if you have changed *any*
configuration setting, you then get prompted for *all* configuration
changes in the package, which I think is Enrico's point. And I agree, I
kind of like that behavior. Configuration settings can interact in
unexpected ways, so if I've had to customize the configuration, I kind of
like knowing when other defaults change. They may affect the thing I had
to customize.

> If the configuration upgrade might matter to sysadmins, the Debian
> package should provide an upgrade note in NEWS.Debian, or upstream
> should provide a note in NEWS (which I wish apt-listchanges could show,
> at least when it follows a standard format).

Upstream's NEWS generally has *way* too much noise to expect people to
look at it by default. NEWS.Debian isn't a horrible solution, but it
doesn't provide a way of saying "no, don't apply this change but still
continue with the package installation," which I think you need for
configuration files.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k45de69a.fsf@windlord.stanford.edu">http://lists.debian.org/87k45de69a.fsf@windlord.stanford.edu
 

Thread Tools




All times are GMT. The time now is 04:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org