Bug 782222 - kde-printer-applet-debuginfo is empty
Summary: kde-printer-applet-debuginfo is empty
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-printer-applet
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-16 21:18 UTC by Ville Skyttä
Modified: 2012-01-17 13:04 UTC (History)
6 users (show)

Fixed In Version: kde-printer-applet-4.7.97-2.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-17 13:04:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ville Skyttä 2012-01-16 21:18:15 UTC
kde-printer-applet-debuginfo 4.7.97-1 is empty.  Should the package be noarch?

Comment 1 Rex Dieter 2012-01-16 23:20:46 UTC
It's contents certainly are all noarch, I'll have to doublecheck none of it's dependencies need to be arch'd before doing so.

OK, looks like we probably will need arch'd deps much like how system-config-printer's deps are handled as well.  I assume the same problem applies for system-config-printer wrt -debuginfo as well?

Comment 2 Rex Dieter 2012-01-17 00:48:31 UTC
Yeah, mostly, except it does seem to include at least one binary helper for system-config-printer-udev, so system-config-printer-debuginfo isn't empty like ours.

I'm thinking we need 2 things then:
1. suppress -debuginfo generation
2. make Requires: arch'd properly

Comment 3 Kevin Kofler 2012-01-17 00:54:31 UTC
kde-printer-applet should just be noarch. It's perfectly fine for a noarch package to have dependencies on arch-specific packages (just don't try to %{?_isa} them, obviously).

Comment 4 Rex Dieter 2012-01-17 01:29:14 UTC
well, making the dependencies arch'd would be more correct.  For example, on a multilib'd x86_64 box, while kde-printer-applet works fine with pykde.x86_64, it won't with pykde.i686

Comment 5 Rex Dieter 2012-01-17 01:37:15 UTC
that said, I'm ok with just noarch'ing it.  it's simpler and should work by default, unless someone goes out of their way to install non-native arch'd deps to break it.

Comment 6 Rex Dieter 2012-01-17 13:04:20 UTC
ok, went with the noarch approach, fixed in 4.7.97-2


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