|
Home > Archive > Debian Developers > October 2004 > software updates file in /usr -- policy bug?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
software updates file in /usr -- policy bug?
|
|
| martin f krafft 2004-10-25, 5:52 pm |
| Hi all,
apt-spy and pciutils (and possibly others) contain methods to update
a database integral to their operation.
- `apt-spy update` downloads the list of available Debian mirrors
to /usr/share/apt-spy (see #277816).
- `update-pciids` downloads a new /usr/share/misc/pci.ids
I think these are both in violation with the FHS, which states
(Chapter 4, emphasis mine, using caps instead of asterisks for
readability):
"/usr is shareable, READ-ONLY DATA. That means that /usr should be
shareable between various FHS-compliant hosts and MUST NOT BE
WRITTEN TO."
The apt-apy maintainer thinks this is okay because (from the bug
report):
apt-spy does not "dynamically update". It updates *if and ONLY
if* you ask it to. I do not see this as a violation of the spirit
of the FHS. I'm more than happy to have discussion about this.
If this holds, then why does `apt-get update` modify files in
/var/lib/apt/lists, and why is /var/lib/dpkg/status not really
/usr/lib/dpkg/status?
Well, two wrongs don't make a right, nor does APT/dpkg's choice for
/var make using /usr for changeable resource data wrong for
everyone, but I still think that apt-spy's mirror list and the PCI
IDs should be kept in /var, since they are variable data.
Looking forward to comments!
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Santiago Vila 2004-10-25, 5:52 pm |
| On Mon, 25 Oct 2004, martin f krafft wrote:
> Hi all,
>
> apt-spy and pciutils (and possibly others) contain methods to update
> a database integral to their operation.
>
> - `apt-spy update` downloads the list of available Debian mirrors
> to /usr/share/apt-spy (see #277816).
>
> - `update-pciids` downloads a new /usr/share/misc/pci.ids
>
> I think these are both in violation with the FHS, which states
> (Chapter 4, emphasis mine, using caps instead of asterisks for
> readability):
>
> "/usr is shareable, READ-ONLY DATA. That means that /usr should be
> shareable between various FHS-compliant hosts and MUST NOT BE
> WRITTEN TO."
>
> The apt-apy maintainer thinks this is okay because (from the bug
> report):
>
> apt-spy does not "dynamically update". It updates *if and ONLY
> if* you ask it to. I do not see this as a violation of the spirit
> of the FHS. I'm more than happy to have discussion about this.
>
> If this holds, then why does `apt-get update` modify files in
> /var/lib/apt/lists, and why is /var/lib/dpkg/status not really
> /usr/lib/dpkg/status?
>
> Well, two wrongs don't make a right, nor does APT/dpkg's choice for
> /var make using /usr for changeable resource data wrong for
> everyone, but I still think that apt-spy's mirror list and the PCI
> IDs should be kept in /var, since they are variable data.
Having a program asking the user "do you want to violate the FHS?"
does not make it not to be a violation. I would much prefer not to
have to answer such questions.
Some people might want to have /usr mounted read-only except when
using dpkg/apt to upgrade the system. The FHS says this should work,
so any program which fails because it tries to write to /usr could be
considered as a bug.
Even if the file is updated only by the postinst, it is useful to know
that you can recover a broken system from scratch by having:
* A backup copy of /etc, /var, /home, /usr/local, etc. (but not /usr).
* The list of installed packages.
I think this is a good property of the system that we should try to keep.
Would the user benefit from having the freedom to change apt-spy or pci.ids?
If yes, then those files would be much better placed in /etc. Just because
it is a "database" does not mean it may not be modified by the user.
Think about /etc/services for example.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2004-10-26, 5:51 pm |
| For reference, here are two points that came up on IRC:
- The administrator has no place in /usr, it's the package
manager's domain.
- Tools keep MD5 sums for files installed. When a file in /usr
changes, it is usually an indication of something fishy; thus,
certain programmes will fire alarms.
Lastly, the policy promises that /usr can be read-only and
guarantees software to be fully functional.
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Frank Küster 2004-10-26, 5:51 pm |
| martin f krafft <madduck@debian.org> schrieb:
> For reference, here are two points that came up on IRC:
It's good that you keep us non-chatters informed. However:
> - The administrator has no place in /usr, it's the package
> manager's domain.
>
> - Tools keep MD5 sums for files installed. When a file in /usr
> changes, it is usually an indication of something fishy; thus,
> certain programmes will fire alarms.
>
> Lastly, the policy promises that /usr can be read-only and
> guarantees software to be fully functional.
Now, where is the possible policy bug?
Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer
| |
| martin f krafft 2004-10-26, 5:51 pm |
| also sprach Frank Küster <frank@debian.org> [2004.10.26.1916 +0200]:
>
> Now, where is the possible policy bug?
Section 9.1.1 of the policy. The software writes to /usr, which is
to be treated as read-only at any time other than package
management. Thus, effectively, dpkg is the only tool allowed to
manipulate files in /usr, though other tools are used from time to
time (e.g. ln(1)), but only during installation or removal of the
owner package.
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| sean finney 2004-10-26, 5:51 pm |
| hey martin,
On Tue, Oct 26, 2004 at 05:47:03PM +0200, martin f krafft wrote:
> - The administrator has no place in /usr, it's the package
> manager's domain.
>
> - Tools keep MD5 sums for files installed. When a file in /usr
> changes, it is usually an indication of something fishy; thus,
> certain programmes will fire alarms.
>
> Lastly, the policy promises that /usr can be read-only and
> guarantees software to be fully functional.
fwiw i think it's Very Wrong that any package or tool should try and update
the contents of anything in /usr outside of placing their pre-packaged
files in there[1]. if this information is variable state, then it should
go where variable state information is supposed to go, no question about
it. if the admin should be able to edit it, there's a place for that
too. neither of these is /usr...
sean
[1] of course, symlinks, diversions, etc all fall in the same spirit.
--
| |
| Steve Langasek 2004-10-26, 5:51 pm |
| On Tue, Oct 26, 2004 at 07:16:47PM +0200, Frank Küster wrote:
> martin f krafft <madduck@debian.org> schrieb:
[vbcol=seagreen]
> It's good that you keep us non-chatters informed. However:
[vbcol=seagreen]
> Now, where is the possible policy bug?
It isn't a policy bug at all; it's a case of a package that's violating
policy. (apt-spy, if the thread parent is no longer apparent.)
--
Steve Langasek
postmodern programmer
| |
| Manoj Srivastava 2004-10-26, 5:51 pm |
| On Tue, 26 Oct 2004 19:45:15 +0200, martin f krafft <madduck@debian.org> said:
> also sprach Frank Küster <frank@debian.org> [2004.10.26.1916 +0200]:
[vbcol=seagreen]
> Section 9.1.1 of the policy. The software writes to /usr, which is
> to be treated as read-only at any time other than package
> management. Thus, effectively, dpkg is the only tool allowed to
> manipulate files in /usr, though other tools are used from time to
> time (e.g. ln(1)), but only during installation or removal of the
> owner package.
Again, what's the policy bug?
manoj
--
Zeus gave Leda the bird.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Frank Küster 2004-10-26, 5:51 pm |
| martin f krafft <madduck@debian.org> schrieb:
> also sprach Frank K=FCster <frank@debian.org> [2004.10.26.1916 +0200]:
>
> Section 9.1.1 of the policy. The software writes to /usr,=20
You should probably tell us non-chatters what "The software" is...=20
Good night, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer
| |
|
| Martin,
On Tue, Oct 26, 2004 at 07:45:15PM +0200, martin f krafft wrote:
> also sprach Frank Küster <frank@debian.org> [2004.10.26.1916 +0200]:
>
> Section 9.1.1 of the policy. The software writes to /usr, which is
> to be treated as read-only at any time other than package
> management. Thus, effectively, dpkg is the only tool allowed to
> manipulate files in /usr, though other tools are used from time to
> time (e.g. ln(1)), but only during installation or removal of the
> owner package.
Are we reading the same policy?
Debian Policy Manual
Chapter 9 - The Operating System
9.1 Filesystem hierarchy
9.1.1 Filesystem Structure
The location of all installed files and directories must
comply with the Filesystem Hierarchy Standard (FHS) ...
(should 'hierarchy' have a capital, or perhaps 'Structure' not?)
What software writes to /usr ?
If you're refering to 9.1.2 that seems not too far from the FHS.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2004-10-26, 5:51 pm |
| also sprach Manoj Srivastava <srivasta@debian.org> [2004.10.26.2104 +0200]:
> Again, what's the policy bug?
#277816
< vorlon> Manoj: it's not a policy bug, just a shitty subject line.
I guess I could not say it better. It's not a bug in the policy,
just a bug according to policy.
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| martin f krafft 2004-10-27, 2:49 am |
| also sprach paddy <paddy@panici.net> [2004.10.26.2114 +0200]:
> Are we reading the same policy?
There is only one.
> Debian Policy Manual
> Chapter 9 - The Operating System
> 9.1 Filesystem hierarchy
> 9.1.1 Filesystem Structure
>
> The location of all installed files and directories must
> comply with the Filesystem Hierarchy Standard (FHS) ...
Exactly.
> What software writes to /usr ?
As noted in the OP, apt-spy, pciutils, and probably others.
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Mike Hommey 2004-10-28, 2:48 am |
| On Mon, Oct 25, 2004 at 07:44:19PM +0200, Santiago Vila wrote:
> Even if the file is updated only by the postinst, it is useful to know
> that you can recover a broken system from scratch by having:
>
> * A backup copy of /etc, /var, /home, /usr/local, etc. (but not /usr).
> * The list of installed packages.
.... which can, anyway, got back from files in /var
Mike
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2004-10-28, 7:49 am |
| also sprach Frank Küster <frank@debian.org> [2004.10.26.2057 +0200]:
> You should probably tell us non-chatters what "The software" is...
I believe the original post had the reference: apt-spy, pciutils,
usbutils, possibly others. Note that usbutils and apt-spy are
already fixed.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Frank Küster 2004-10-28, 5:52 pm |
| martin f krafft <madduck@debian.org> schrieb:
> also sprach Frank K=FCster <frank@debian.org> [2004.10.26.2057 +0200]:
>
> I believe the original post had the reference: apt-spy, pciutils,
> usbutils, possibly others.=20
The original post reached my inbox just a couple of minutes ago,
together with some answers. I hope it's not an ext3 problem again...=20
Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer
| |
|
| On Wed, Oct 27, 2004 at 08:28:26AM +0200, martin f krafft wrote:
> also sprach paddy <paddy@panici.net> [2004.10.26.2114 +0200]:
>
> As noted in the OP, apt-spy, pciutils, and probably others.
My apologies, I only just got that post today!
I dived in a little early, but I've read that and #277816,
so I may as well throw in my twopenneth:
IMHO, The FHS is a little fuzzy on /usr/share:
Any program or package which contains or requires data that doesn't
need to be modified should store that data in /usr/share
In any case, I imagine wanting to support the degenerate case of
/usr/share on a /usr filesystem mounted ro.
I have sympathy with 'the administrator does it'. And I believe in
supplying the best possible tools for the administrator.
By default, data which might otherwise live under /usr, but is
moved out because it is variable, would go to /var somewhere
(or a better place if one exists).
So the question must be:
What use is served by keeping this data in /usr/share?
I'd also question whether this data is truly 'not host specific'.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chris Cheney 2004-10-29, 2:49 am |
| On Mon, Oct 25, 2004 at 07:11:45PM +0200, martin f krafft wrote:
> Hi all,
>
> apt-spy and pciutils (and possibly others) contain methods to update
> a database integral to their operation.
>
> - `apt-spy update` downloads the list of available Debian mirrors
> to /usr/share/apt-spy (see #277816).
>
> - `update-pciids` downloads a new /usr/share/misc/pci.ids
>
> I think these are both in violation with the FHS, which states
> (Chapter 4, emphasis mine, using caps instead of asterisks for
> readability):
>
> "/usr is shareable, READ-ONLY DATA. That means that /usr should be
> shareable between various FHS-compliant hosts and MUST NOT BE
> WRITTEN TO."
dpkg should not put files in /usr when it extracts programs either if
/usr MUST NOT BE WRITTEN TO... ;)
Chris
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2004-10-29, 2:49 am |
| also sprach Chris Cheney <ccheney@cheney.cx> [2004.10.29.0823 +0200]:
> dpkg should not put files in /usr when it extracts programs either if
> /usr MUST NOT BE WRITTEN TO... ;)
Come on! The FHS regulates what normal software can/should do,
partially so that package managers can work reliably. dpkg is the
package manager, thus it is exempt from the FHS.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Wouter Verhelst 2004-10-29, 2:49 am |
| On Fri, Oct 29, 2004 at 08:49:54AM +0200, martin f krafft wrote:
> also sprach Chris Cheney <ccheney@cheney.cx> [2004.10.29.0823 +0200]:
^^[vbcol=seagreen]
> Come on! The FHS regulates what normal software can/should do,
> partially so that package managers can work reliably. dpkg is the
> package manager, thus it is exempt from the FHS.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2004-10-29, 2:49 am |
| also sprach Wouter Verhelst <wouter@grep.be> [2004.10.29.1002 +0200]:[vbcol=seagreen]
> ^^
I noted the smiley. I still wanted to make it explicit.
In fact, I should have been even clearer. The FHS applies to the
filesystem structure are run-time, not at installation time. It
guides the installation, but only such that when the installation
phase is complete, the system can switch to run-time and be
FHS-compliant from the start onwards.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Anthony Towns 2004-10-30, 5:49 pm |
| On Fri, Oct 29, 2004 at 10:14:08AM +0200, martin f krafft wrote:
> In fact, I should have been even clearer. The FHS applies to the
> filesystem structure are run-time, not at installation time. It
> guides the installation, but only such that when the installation
> phase is complete, the system can switch to run-time and be
> FHS-compliant from the start onwards.
That's not quite true -- dpkg can't stick stuff in /debian-rocks/bin and
claim to be FHS compliant. The key point is the distinction between who
is controlling the file, and what it's for: the vendor (us) puts stuff
in /usr, the admin puts software in /usr/local, and programs put their
data in /var, ~, or /srv, depending on what sort of data it is (internal,
personal work, or shared work).
Having apt-spy dpkg-divert the file in /usr on install, and replace it
with a symlink to a file in /var/lib, and then update the file in /var/lib
when invoked seems the obviously correct way to deal with this, no?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
Don't assume I speak for anyone but myself. GPG signed mail preferred.
``[S]exual orgies eliminate social tensions and ought to be encouraged.''
-- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)
| |
| martin f krafft 2004-10-30, 5:49 pm |
| also sprach Anthony Towns <aj@azure.humbug.org.au> [2004.10.30.0713 +0200]:
> Having apt-spy dpkg-divert the file in /usr on install, and
> replace it with a symlink to a file in /var/lib, and then update
> the file in /var/lib when invoked seems the obviously correct way
> to deal with this, no?
Why dpkg-divert? Why have a symlink in /usr at all (unless there is
another software that hardcodes the path...)
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Stephen Stafford 2004-10-30, 8:46 pm |
| Anthony Towns wrote:
> On Fri, Oct 29, 2004 at 10:14:08AM +0200, martin f krafft wrote:
>
>
>
> That's not quite true -- dpkg can't stick stuff in /debian-rocks/bin and
> claim to be FHS compliant. The key point is the distinction between who
> is controlling the file, and what it's for: the vendor (us) puts stuff
> in /usr, the admin puts software in /usr/local, and programs put their
> data in /var, ~, or /srv, depending on what sort of data it is (internal,
> personal work, or shared work).
>
> Having apt-spy dpkg-divert the file in /usr on install, and replace it
> with a symlink to a file in /var/lib, and then update the file in /var/lib
> when invoked seems the obviously correct way to deal with this, no?
>
In the end, after my irritation at how the NMU was done abated, I just
moved the file to /var/lib/apt-spy. Most people seemed to agree this
was the correct location. Nothing else depends on the location of the
file, so a symlink isn't required.
In a future version of apt-spy we might provide a config file which sets
(among other things) where to get the file from. That then allows the
network admin to set a location for his own version (the main reason it
was in /usr/share in the first place) and then I think the file would be
in the right place...for now it will do, although I don't think it's
ideal.
Steven Holmes is looking to extend apt-spy's functionality to make it do
a similar job for BSD mirrors and for other Linux distributions. A
configuration file to modify behaviour will be part of this extension.
I'm not going to upload this before etch (assuming it's even ready
before then - how long is sarge's release likely to be?). Right now I
don't want to make too many uploads of new features...I'd like a release
sometime sooner rather than later after all 
Cheers,
Stephen
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|