Bug 496171

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

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?

> Is there any reason to keep the old stack around?

Maybe as a workaround for a brasero bug ?

Matthias, what's your opinion ?

I think obsoleting n-c-b is the right thing to do.

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 ?

Since this is in essence replacing nautilus-cd-burner, you should follow https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages

Done:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1304538

Denis, did you file a ticket to get this tagged for F11 ?

https://fedorahosted.org/rel-eng/ticket/1540

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)

?

Sure. I assume those need to be tagged for f11 as well.

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).

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 ?

Yikes, yes s/brasero/nautilus/ in that last paragraph, was 1:30 am when I wrote that...

(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.

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 ?

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.

> 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 ?

(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.

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 ?

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.

Ok, thanks spot

All done. nautilus-cd-burner-2.25.3-7.fc11 is tagged into dist-f11.