Moving to devel, it isn't critical enough to have an rpm update in FC5. See also
bug #204608 for a related entry.

/etc/rpm/macros should not be distributed with rpm, nor should its contents be altered
by any application. The file is intended for per-system configuration, and there are many
alternative means to configure per-system without "owning" or altering the file /etc/rpm/macros.

WONTFIX

You don't address the fact that the file remains unowned - one of the very few
unowned files unter /etc. I agree that default system configuration needs to be
elsewhere, but that's unrelated to file ownership.

As far as applications modifying it are concerned I already referred to bug
#204608, but that's also unrelated to file ownership and better dicussed in that
bug submission.

You don't address the fact that the file is not needed or used (anaconda should have
written the definition of %_transaction_color into a different file. In fact, %_transaction_color
needs to be defaulted to 3 on all platforms, the idea that one can configure multilib
behavior is as wrong as LD_ASSUME_KERNEL was, i.e. not designed for "production" use).

Sure whatever config file that anaconda chooses to write into might reasonably
be expected to be owned by anaconda, not rpm.

I also point out that there are many per-system config files that are not "owned"
by packages:
    $ rpm -qf /etc/sysconfig/* | grep 'not owned' | wc -l
    25
on my FC system. So /etc/rpm/macros is just another per-system configuration file.

WONTFIX in the sense that there is no need to deliver a unused/unneeded empty file
to preserve a imperfectly followed convention for "ownership" in /etc of your devising.

Justifying a bug, because there are other bugs in other packages (and how many
false positives like *~, *.rpmnew/rpmsave, *.bak did you count with the above? A
very complete FC5/x86_64 install only has about 10 correct positives, aka bugs
in file ownerships)

I'm not justifying a bug, I'm fixing rpm problems.

In fact, writing /etc/rpm/macros has been unnecessary for quite some time,
since the default value of %_transaction color has been (and should be) set in
/usr/lib/rpm/macros, not in /etc/rpm/macros.

Here's is the relevant portion or macros.in, @RPMCANONCOLOR@ is detected and
set at build time:

#       The default transaction color. This value is a set of bits to
#       determine file and dependency affinity for this arch.
#               0       uncolored (i.e. use only arch as install hint)
#               1       Elf32 permitted
#               2       Elf64 permitted
%_transaction_color     @RPMCANONCOLOR@

So /etc/rpm/macros is not used or needed by rpm.

Here's the macrofiles directive:

    macrofiles:     @RPMCONFIGDIR@/macros:@RPMCONFIGDIR@/%{_target}/macros:@SYSCONFIGDIR@/
macros.*:@SYSCONFIGDIR@/macros:@SYSCONFIGDIR@/%{_target}/macros:~/.rpmmacros

Please note that there are many files that might be read by rpm that don't normally exist
and that are not "owned".

Please also note the existence of a "macros.*" glob, so establishing "owner" in packaging
for files who's paths are unknown is literally impossible.

Now why exactly should /etc/rpm/macros be treated any different than all the other
paths that might conceivably be used for rpm configuration?

Please move this bug to ananconda if you wish to discuss further, as anaconda
created the file, and therefor should "own" /etc/rpm/macros if anaconda wishes.

Sure there are false positives. But even 10 unowned files (your reported count) in
/etc/sysconfig demonstrates that there is no strong convention that all files in
/etc should be "owned".

Jeff, you keep returning to anaconda which is unrelated to this bug, I refer for
the third time to bug #204608, where your comments might be better placed.

/etc/rpm/macros is a prominent file for rpm. For a long time it was the only
config file, globbed macros.* are a recent thing. Therefore most documentation
on modifying rpm behaviour uses /etc/rpm/macro. Even a bugzilla user named Jeff
Johnson very often recommended to bug submitters to place something in there for
testing/fixing things.

It simply is the core user config file. And as for any other application it
should be owned by the application.

And there is a convention for packages owning their config files since the ice
ages. Bugs, even minor ones, don't justify more bugs.

Jeff, please don't comment on a bug filed against the rpm PACKAGE for a Fedora
product.  The bug is not against the RPM SOFTWARE, rather the PACKAGING of it,
and last I checked, you are not responsible for packaging RPM for Fedora products.

Define "recent" please. The glob has been part of rpm distributed
by FC since FC2, which means is in RHEL4.

Furthermore, even the macrofiles: directive is overridable by
rpm configuration.

rpm has never included the path /etc/rpm/macros, and has never
distributed any configuration necessary for rpm functionality
within that path.

I see no reason to add a zero length empty file marked %config(norplace)
or otherwise, in rpm packaging so that the "prominence" of one of many ways of
configuring rpm is somehow conveyed to users.

There is no convention for packages to own all possible sources of configuration,
even the "prominent" paths, that has ever existed AFAIK. Does bash (or some other
package) own all possible paths of configuring /bin/sh?

Jesse: please feel free to add any comments you have wrto rpm owning
the path /etc/rpm/macros whenevr you have something relevant to say.

Jesse:  Since when were you elected Bugzilla Nazi?  Anyone is free to comment on
any bug he wishes in any manner he sees fit.  Jeff's opinion on this bug has
significance, as he is the foremost authority on RPM in the world, and your
comment is nothing but flamebait.

If you don't want the general public commenting on bugs in Bugzilla, fix the
permissions so they can't.  Otherwise, man up and get over yourself already.

(In reply to comment #10)
> Jesse: please feel free to add any comments you have wrto rpm owning
> the path /etc/rpm/macros whenevr you have something relevant to say.

If anaconda folks deem that there truely is a need for them to populate the
file, then yes, the rpm PACKAGE should own it to ensure proper file ownership. 
This is a packaging decision, not necessarily something "upstream" needs to
worry/care about.

Axel, this bug should probably be dependant on the anaconda bug.  If anaconda
truely doesnt need that content anymore, then no Fedora package would be
creating the macros file and it should be left to administrator space.

Jesse: Good call! Adding %config(noreplace) in order to create
/etc/rpm/macros.rpmnew for all FC users who have chosen
to configure rpm per-system would have been messy indeed.

And -- for better or worse -- %transaction_color is 3 on all multilib
capable platforms (note I don't consider ia64 emulaion "multilib" capable)
is the default "production" setting, there is no reason why anaconda needs
to write that value any more.

User pnasrat's account has been closed

Reassigning to owner after bugzilla made a mess, sorry about the noise...

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

/etc/rpm/macros is still not owned by rpm, but at least anaconda does not create
this file anymore on current rawhide/x86_64. Still IMHO it should be owned by rpm.

The file doesn't exist by default, does it?  What would having a site-specific
file owned by rpm gain?

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I don't see much point in owning files that doesn't normally exist. Otherwise we'd have to own many many other files too... WONTFIX as anaconda no longer creates the file.