Bug 59133 - docbook-dtds-1.0-2 creates a bunch of files that it doesn't own
Summary: docbook-dtds-1.0-2 creates a bunch of files that it doesn't own
Keywords:
Status: CLOSED DUPLICATE of bug 193475
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: docbook-dtds
Version: 1.0
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-01-31 16:11 UTC by Jonathan Kamens
Modified: 2007-05-21 13:25 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-21 13:25:14 UTC
Embargoed:


Attachments (Terms of Use)

Description Jonathan Kamens 2002-01-31 16:11:54 UTC
rpmbackup.pl: /etc/sgml/catalog is not in any package
rpmbackup.pl: /etc/sgml/sgml-docbook-3.0-1.0-2.cat is not in any package
rpmbackup.pl: /etc/sgml/sgml-docbook-3.1-1.0-2.cat is not in any package
rpmbackup.pl: /etc/sgml/sgml-docbook-4.0-1.0-2.cat is not in any package
rpmbackup.pl: /etc/sgml/sgml-docbook-4.1-1.0-2.cat is not in any package
rpmbackup.pl: /etc/sgml/xml-docbook-4.1.2-1.0-2.cat is not in any package

(Actually, /etc/sgml/catalog may be a problem with sgml-common rather than with
docbook-dtds, but I leave that to you to figure out).

if installing docbook-dtds is going to create the files above, then they should
be listed in the docbook-dtds RPM so that RPM knows that it owns these files.

Comment 1 Tim Waugh 2002-01-31 17:01:33 UTC
Suggest a way of fixing it.  These are created post-install.


Comment 2 Jonathan Kamens 2002-01-31 17:14:16 UTC
There are plenty of other official Red Hat RPMS which solve this problem. 
Consult them.  I think the new support in RPM for "ghost files" may be relevant.


Comment 3 Tim Waugh 2002-01-31 17:33:51 UTC
Well, the same goes for all the files in /etc/rc*.d.


Comment 4 Jonathan Kamens 2002-01-31 17:38:31 UTC
What are you talking about?  All of the files in /etc/rc.d are correctly owned
by their respective packages?  And what does /etc/rc.d have to do with
/etc/sgml?

jik:/usr/src/packages/new!43> find /etc/rc.d -type f -print | xargs rpm -q -f
apmd-3.0.2-5
netatalk-1.5pre2-6
at-3.1.8-23
autofs-3.1.7-25
vixie-cron-3.0.1-64
diald-0.99.1-2
initscripts-6.50-1
gpm-1.19.6-1
initscripts-6.50-1
apache-1.3.22-4
pidentd-3.0.14-4
inn-2.3.2-6
ipchains-1.3.10-12
krb5-libs-1.2.3-4
console-tools-19990829-36
initscripts-6.50-1
kudzu-0.99.45-1
linuxconf-1.25r7-4
ntp-4.1.0b-5
kernel-utils-2.4-2.4
bind-9.2.0-3
initscripts-6.50-1
initscripts-6.50-1
nfs-utils-0.3.3-2
nfs-utils-0.3.3-2
ntop-1.3.2-5
lpr-0.50-4
portmap-4.0-40
initscripts-6.50-1
initscripts-6.50-1
sendmail-8.11.6-9jik
initscripts-6.50-1
kernel-utils-2.4-2.4
samba-2.2.2-10
ucd-snmp-4.2.1-9
openssh-server-3.0.2p1-2
sysklogd-1.4.1-5
vnc-server-3.3.3r2-26
samba-common-2.2.2-10
XFree86-xfs-4.2.0-3.2
xinetd-2.3.4-1.4
cups-1.1.13-1
initscripts-6.50-1
initscripts-6.50-1
initscripts-6.50-1
jik:/usr/src/packages/new!44> 

I do not understand why you deferred this bug.  I have reported this particular
problem about many RPMs, and every time I've done so in the past, the developer
responsible for the RPM has acknowledged the problem and fixed it.  Why should
this RPM be exempt from Red Hat's packaging standards?


Comment 5 Tim Waugh 2002-01-31 17:53:08 UTC
I said rc*.d, not rc.d.  Try 'rpm -qf /etc/rc*.d/*' and you may be surprised.

The files that are created are done so in the postinstall script, and so are not
in the file list.

%ghost doesn't work in this context, apparently: try it and you'll see what I mean.

The maintenance of these files is delicate enough without having rpm delete them
after upgrade because it thinks it should:

[root@turmoil redhat]# rpm -Fvh ./RPMS/noarch/docbook-dtds-1.0-5.noarch.rpm
Preparing...                ########################################### [100%]
   1:docbook-dtds           ########################################### [100%]
Failed to removed entry from /etc/sgml/sgml-docbook-3.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-3.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-3.1-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-3.1-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.1-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.1-1.0-4.cat
Failed to removed entry from /etc/sgml/xml-docbook-4.1.2-1.0-4.cat
Failed to removed entry from /etc/sgml/xml-docbook-4.1.2-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-3.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-3.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-3.1-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-3.1-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.0-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.1-1.0-4.cat
Failed to removed entry from /etc/sgml/sgml-docbook-4.1-1.0-4.cat
Failed to removed entry from /etc/sgml/xml-docbook-4.1.2-1.0-4.cat
Failed to removed entry from /etc/sgml/xml-docbook-4.1.2-1.0-4.cat

If you find a nice way to get this to work without it messing up those files on
upgrade, let me know and I will happily use that.

Comment 6 Jonathan Kamens 2002-01-31 18:11:43 UTC
1) The symlinks in /etc/rc*.d are a specific exception to the rule that packages
must own the files that they create.  You can't apply that specific exception to
the entire filesystem.

2) It's impossible for packages to own the links in /etc/rc*.d because the
packages don't even know what links will be created -- that's dynamic based on
whether the services are enabled and for which runlevels.  On the other hand,
the files created by docbook-dtds are static, are they not?  I.e., the packager
knows exactly which files are going to be created during install.

3) I don't think it's my job to tell you how to fix this bug.  Unfortunately, I
don't know for certain what the right answer is.  All I know is that many other
RPMs have had this same problem and most of them have been fixed.  Why don't you
talk to other package maintainers and ask them?  If %ghost doesn't work, another
possible strategy is to create empty files during installation and then replace
them with the actual generated files, but if you do this, you probably need to
say in the spec file that the size, checksum and mod time of these files should
be ignored during rpm --verify.

Other bugs of this sort  that I've reported for other packages, that have been
fixed ,include 50699 and 49234.


Comment 7 Tim Waugh 2002-01-31 18:22:21 UTC
The other packagers (in fact, the rpm maintainer) say 'rpm manages packages, not
files'.

I tried %ghost and %config(missingok), neither of which do the right thing here.

Comment 8 Bill Nottingham 2006-08-08 02:06:44 UTC
'Red Hat Raw Hide' refers to the development tree for Red Hat Linux.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues were not resolved in a more
timely manner. However, we do want to make sure that important 
don't slip through the cracks. If these issues are still present
in a current release, such as Fedora Core 5, please move these
bugs to that product and version. Note that any remaining Red Hat
Raw Hide bugs will be closed as 'CANTFIX' on September 30, 2006.
Thanks again for your help.


Comment 9 Bill Nottingham 2006-10-18 19:43:04 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

Comment 10 Jonathan Kamens 2006-11-26 19:08:08 UTC
This is still broken in Fedora Core.


Comment 11 Ondrej Vasik 2007-05-21 13:25:14 UTC
But for Fedora Core there is already a ticket opened about this issue (#193475),
no reason for having this ticket reopened. Closing as Duplicate...

*** This bug has been marked as a duplicate of 193475 ***


Note You need to log in before you can comment on or make changes to this bug.