On 02/16/2013 05:16 PM, Kevin Fenzi wrote:
On Sat, 16 Feb 2013 13:47:13 +0200
Panu Matilainen <pmati...@laiskiainen.org> wrote:
I think Kevin was talking about "normal", ie non-debuginfo packages
like the example case of nacl-devel owning /usr/lib/debug, which
indeed is a (trivial) packaging bug. Except perhaps for the
filesystem package which is fairly special case anyway.
Indeed I was. I was thinking we were talking about packages that
mistakenly are shipping their debuginfo in the real package.
OTOH because -debuginfo packages always own all the relevant
directories there's no need for filesystem to own them, which would
allow for a nice and clean rule: any non-debuginfo package owning the
*debug directories can be considered an unnecessary multiple
directory ownership (and a bug of sorts).
Sounds fine to me.
kevin
OK, I have caused some confusion and headaches here. Sorry for that
Thanks for all replies, I certainly understand this better now. That is
not to say there's nothing more in this. Trying to summarize conclusions:
- We have one trivial packaging bug where an ordinary (nacl-devel)
package erroneously owns a debug package. Michael reported this as BZ
911405.
- Filesystem owns /usr/src/debug but not /usr/lib/debug. No big deal,
but still inconsistent. I reported this as BZ911831.
- Directories in /usr/{src,lib}/debug are owned by auto-generated
dependencies for debuginfo packages. Each package owns the complete
directory chain. While not absolutely kosher, it's a practical solution
which works without worse problems than some left, empty directories in
some cases.
- For fedora-review, my personal starting point, is a directory owned by
the reviewed package which also is owned by some other package something
which needs a motivation. That's not to say it's an error. This does not
apply to debuginfo packages, which by definition have correct,
auto-generated dependencies.
Hope I got it right...
Cheers!
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
