Bug 496171 - brasero-nautilus should Obsolete (and provide) nautilus-cd-burner
brasero-nautilus should Obsolete (and provide) nautilus-cd-burner
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: brasero (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Denis Leroy
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2009-04-16 19:19 EDT by Jesse Keating
Modified: 2013-01-09 22:29 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-23 18:50:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jesse Keating 2009-04-16 19:19:42 EDT
Without this nautilus-cd-burner will remain installed and used for burning from within Nautilus.
Comment 1 Denis Leroy 2009-04-16 19:36:51 EDT
Normally even if nautilus-cd-burner is installed, the brasero stack should be used (IF brasero-nautilus is installed). In the end it comes down to what is being installed by default. If somebody is using nautilus-cd-burner from F-10 and doing an upgrade to F-11, they will keep using nautilus-cd-burner since brasero-nautilus won't get install auto-magically. While a fresh F-11 install, from the live CD for example, will install the brasero stack but not nautilus-cd-burner. Isn't this what we want ? If we make brasero Require brasero-nautilus and obsolete nautilus-cd-burner, we might as well orphan nautilus-cd-burner altogether and remove it from the repo...

-denis
Comment 2 Jesse Keating 2009-04-16 19:58:55 EDT
I thought we wanted to do away with nautilus-cd-burner, and move folks to Brasero.  Is there any reason to keep the old stack around?
Comment 3 Denis Leroy 2009-04-17 09:29:01 EDT
> Is there any reason to keep the old stack around?

Maybe as a workaround for a brasero bug ?

Matthias, what's your opinion ?
Comment 4 Matthias Clasen 2009-04-17 09:44:25 EDT
I think obsoleting n-c-b is the right thing to do.
Comment 5 Denis Leroy 2009-04-17 12:06:16 EDT
Okay, so let's add to brasero-nautilus:

Obsoletes: nautilus-cd-burner < 2.26.0
Provides: nautilus-cd-burner = %{version}

I assume the Provides: line is required to ensure a user upgrading from F-10 gets brasero-nautilus installed to replace nautilus-cd-burner, right ?
Comment 6 Jesse Keating 2009-04-17 12:36:21 EDT
Since this is in essence replacing nautilus-cd-burner, you should follow https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages
Comment 7 Denis Leroy 2009-04-17 13:52:10 EDT
Done:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1304538
Comment 8 Matthias Clasen 2009-04-20 02:19:22 EDT
Denis, did you file a ticket to get this tagged for F11 ?
Comment 9 Denis Leroy 2009-04-20 03:07:22 EDT
https://fedorahosted.org/rel-eng/ticket/1540
Comment 10 Matthias Clasen 2009-04-21 17:23:50 EDT
Denis, can you also take care of these: 

Broken deps for x86_64
----------------------------------------------------------
        gnome-desktop-sharp-2.26.0-1.fc11.x86_64 requires libnautilus-burn.so.4()(64bit)
        gnome-python2-nautilus-cd-burner-2.26.0-1.fc11.x86_64 requires libnautilus-burn.so.4()(64bit)

?
Comment 11 Denis Leroy 2009-04-21 18:32:59 EDT
Sure. I assume those need to be tagged for f11 as well.
Comment 12 Denis Leroy 2009-04-21 19:38:02 EDT
Okay, there's an issue here. There are 2 leaf packages that depend on nautilus-cd-burner-libs through gnome-python2-nautilus-cd-burner :

> repoquery -q --whatrequires gnome-python2-nautilus-cd-burner
pybackpack-0:0.5.6-3.fc11.noarch
serpentine-0:0.9-4.fc11.noarch

Orphaning both seems extreme to me, but we could only "orphan" brasero-cd-nautilus and keep brasero-cd-nautilus-{libs|devel} around. I can confirm that would be enough to compile gnome-python2-nautilus-cd-burner (with a tiny Require fix to the spec file).
Comment 13 Matthias Clasen 2009-04-21 21:29:31 EDT
You lost me there. brasero-cd-nautilus == nautilus-cd-burner ?

Anyway, sorry if that wasn't clear. I think can obsolete nautius-cd-burner, but we need to keep nautilus-cd-burner-libs around. Bastien, is that correct ?
Comment 14 Denis Leroy 2009-04-22 02:29:45 EDT
Yikes, yes s/brasero/nautilus/ in that last paragraph, was 1:30 am when I wrote that...
Comment 15 Bastien Nocera 2009-04-22 05:06:34 EDT
(In reply to comment #13)
> You lost me there. brasero-cd-nautilus == nautilus-cd-burner ?
> 
> Anyway, sorry if that wasn't clear. I think can obsolete nautius-cd-burner, but
> we need to keep nautilus-cd-burner-libs around. Bastien, is that correct ?  

Yes, the people writing front-ends to nautilus-cd-burner didn't get a chance to port their apps yet.
Comment 16 Denis Leroy 2009-04-23 14:41:53 EDT
So we need to un-orphan nautilus-cd-burner, and only package nautilus-cd-burner-libs and nautilus-cd-burner-devel.

Brasero obsoletes and Provides 'nautilus-cd-burner', so brasero doesn't have to  be rebuilt. 

Matthias, are you taking care of the this ?
Comment 17 Matthias Clasen 2009-04-23 14:57:21 EDT
No, I'm not. I was expecting you to do it. For the 'only package' part, I think it is sufficient to just remove the main %file section.
Comment 18 Denis Leroy 2009-04-23 17:43:20 EDT
> I think it is sufficient to just remove the main %file section

Well I'm not sure that wuold work. If I'm not mistaken, it's not possible to have a spec named 'foo' to only generate 'foo-X' but not 'foo' itself... We'd have to rename the package altogether.

Jesse is it possible to "block" nautilus-cd-burner, while allowing its 2 subpackages (nautilus-cd-burner-libs and nautilus-cd-burner-devel) to live on ?
Comment 19 Jesse Keating 2009-04-23 17:46:20 EDT
(In reply to comment #18)
> > I think it is sufficient to just remove the main %file section
> 
> Well I'm not sure that wuold work. If I'm not mistaken, it's not possible to
> have a spec named 'foo' to only generate 'foo-X' but not 'foo' itself... We'd
> have to rename the package altogether.

See xorg-x11-drivers

> 
> Jesse is it possible to "block" nautilus-cd-burner, while allowing its 2
> subpackages (nautilus-cd-burner-libs and nautilus-cd-burner-devel) to live on ?  

no.
Comment 20 Denis Leroy 2009-04-23 18:10:11 EDT
Well xorg-x11-drivers still generates an 'xorg-x11-drivers' RPM, albeit an empty one. So you're suggesting stripping the installed content so that 'nautilus-cd-burner' becomes an empty RPM ? (while keeping the 2 subpackages intact)

Is that really necessary actually ? After all, brasero-nautilus Provides a higher version of nautilus-cd-burner. So even if we build it here, it can't be installed from yum... So we wouldn't even have to rebuild it, just have rel-eng unblock it. does that make sense ?
Comment 21 Tom "spot" Callaway 2009-04-23 18:35:05 EDT
If you don't have a %files, it won't make a package for it.

Wrote: /home/spot/cvs/sandbox/nautilus-cd-burner/F-11/nautilus-cd-burner-2.25.3-7.fc11.src.rpm
Wrote: /home/spot/cvs/sandbox/nautilus-cd-burner/F-11/x86_64/nautilus-cd-burner-devel-2.25.3-7.fc11.x86_64.rpm
Wrote: /home/spot/cvs/sandbox/nautilus-cd-burner/F-11/x86_64/nautilus-cd-burner-libs-2.25.3-7.fc11.x86_64.rpm
Wrote: /home/spot/cvs/sandbox/nautilus-cd-burner/F-11/x86_64/nautilus-cd-burner-debuginfo-2.25.3-7.fc11.x86_64.rpm

I'm going to unblock and commit a working (libs and devel only) version now.
Comment 22 Denis Leroy 2009-04-23 18:42:28 EDT
Ok, thanks spot
Comment 23 Tom "spot" Callaway 2009-04-23 18:50:59 EDT
All done. nautilus-cd-burner-2.25.3-7.fc11 is tagged into dist-f11.

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