Bug 442343

Looking at the package it doesn't seem like there are actually any binary DLLs,
every does seem to be built from source, they are just bundled, so changing bug
summary.

After checking on #f-spot on irc.gnome.org, it appears that some of these,
namely mono-addins, libgphoto2-devel need to be bundled as they are (currently)
patched versions.

See also this mailing list post from Jesse Keating:

http://www.redhat.com/archives/fedora-devel-list/2008-April/msg01012.html

This is the list of files that f-spot currently installs, and according to
#f-spot irc channel this list is to be expected.  

/usr/bin/f-spot
/usr/bin/f-spot-import
/usr/bin/f-spot-sqlite-upgrade
/usr/lib/f-spot
/usr/lib/f-spot/Cms.dll
/usr/lib/f-spot/Cms.dll.config
/usr/lib/f-spot/FSpot.Core.dll
/usr/lib/f-spot/FSpot.Query.dll
/usr/lib/f-spot/FSpot.Utils.dll
/usr/lib/f-spot/FlickrNet.dll
/usr/lib/f-spot/Mono.Addins.Gui.dll
/usr/lib/f-spot/Mono.Addins.Setup.dll
/usr/lib/f-spot/Mono.Addins.dll
/usr/lib/f-spot/Mono.Addins.dll.config
/usr/lib/f-spot/Mono.Google.dll
/usr/lib/f-spot/NDesk.Glitz.dll
/usr/lib/f-spot/SemWeb.dll
/usr/lib/f-spot/SmugMugNet.dll
/usr/lib/f-spot/Tao.OpenGl.ExtensionLoader.dll
/usr/lib/f-spot/Tao.OpenGl.ExtensionLoader.dll.config
/usr/lib/f-spot/Tao.OpenGl.Glu.dll
/usr/lib/f-spot/Tao.OpenGl.Glu.dll.config
/usr/lib/f-spot/Tao.OpenGl.dll
/usr/lib/f-spot/Tao.OpenGl.dll.config
/usr/lib/f-spot/extensions
/usr/lib/f-spot/extensions/CDExport.dll
/usr/lib/f-spot/extensions/DefaultExporters.addin.xml
/usr/lib/f-spot/extensions/FlickrExport.dll
/usr/lib/f-spot/extensions/FolderExport.dll
/usr/lib/f-spot/extensions/GalleryExport.dll
/usr/lib/f-spot/extensions/PicasaWebExport.dll
/usr/lib/f-spot/extensions/SmugMugExport.dll
/usr/lib/f-spot/f-spot.exe
/usr/lib/f-spot/f-spot.exe.config
/usr/lib/f-spot/f-spot.global.addins
/usr/lib/f-spot/gnome-keyring-sharp.dll
/usr/lib/f-spot/libfspot.so
/usr/lib/f-spot/libfspot.so.0
/usr/lib/f-spot/libfspot.so.0.0.0
/usr/lib/f-spot/libfspoteog.so
/usr/lib/f-spot/libfspoteog.so.0
/usr/lib/f-spot/libfspoteog.so.0.0.0
/usr/lib/f-spot/libfspotjpegtran.so
/usr/lib/f-spot/libfspotjpegtran.so.0
/usr/lib/f-spot/libfspotjpegtran.so.0.0.0
/usr/lib/f-spot/libgphoto2-sharp.dll
/usr/lib/f-spot/libgphoto2-sharp.dll.config


The only problematic DLLs that could potentially be provided by other packages are:

/usr/lib/f-spot/libgphoto2-sharp.dll  (effectively this is upstream for
libgphoto apparently)
/usr/lib/f-spot/Mono.Addins* (a patched version of upstream)
/usr/lib/f-spot/Tao.* (there is an upstream apparently, but it's not yet
packaged by Fedora and not installed in gac yet anyway)
/usr/lib/f-spot/gnome-keyring-sharp.dll (there is upstream, not yet packaged in
Fedora, and not yet stable to be in gac apparently)

The Debian packages has some packages that fix to allow compiling against
mono-addins:

http://svn.debian.org/viewsvn/pkg-cli-apps/packages/f-spot/trunk/debian/patches/

According to Debian maintainer you just need:

"link_system_libs, plus some autoreconf stuff."

There maybe some other useful patches there.

If you're linking against the system mono-addins, ensure that certain
mono-addins bugs are fixed - Debian and Ubuntu had big problems with extensions
disappearing when f-spot was upgraded.

The crucial fix is:
http://svn.debian.org/viewsvn/pkg-cli-libs/packages/mono-addins/trunk/debian/patches/fix_addin_scan.dpatch?rev=3670&view=markup

Debian is also using mono-addins 0.3.1, and I can't remember whether the .1 made
a difference or not.

OK, applied the Debian patch and did rebuild:

http://koji.fedoraproject.org/koji/buildinfo?buildID=46254

Once the mono-addins is also patched as per comment #6 above.  I'll test and
request rel-eng tag for f9-final.

This change should fix bug 442373 too.

This is tagged

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

Switching back to rawhide and ASSIGNED as some of the bundled bits still need to
be patched to use system ones when the system ones have the necessary features.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Not sure what the status is on this, but if it was fixed before, it is present again on x86_64 Fedora 10.  See also bug 465149 and bug 442373.  F-spot still provides 'mono(Mono.Addins)', which it shouldn't.  Tomboy, for one, breaks because of this - it requires mono-addins, not f-spot.

Please remove mono-addins as a 'provides' for f-spot.

Hi Alex,

So far I think there are two major issues with mono packages and local libraries:

1. There is the generic Fedora policy that packages should not use local copies of libraries. There are several reasons like security updates, preventing of redundancy etc. . If a package violates this rule there is usually no functional impact.

2. There is a problem in the mono packaging: A package can claim that it provides a library (like mono(gnome-keyring-sharp) ), but since the library is not in the GAC it is usually not accessible by other programs anyway and so the other packages may be fooled that one of their requirement is fulfilled but it actually isn't. For example there was the problem that tomboy thought that f-spot fulfills the requirement for Mono.Addins. A problem in this category may has functional impact with respect to the dependency resolution of the packet manager. I've already looked whether the problem can be easily fixed in the find-provides/find-requires scripts for mono, but it seems to be a little bit complicated.

It looks like that it is quite common for mono projects to have their own copies of libraries without providing an easy way to choose between the usage of the internal or the one provided by the system. 

Given all these facts, I don't think they can be solved at once and so I think we should start with the most critical ones where a provides of f-spot hides a standalone library. It is IMHO quite hard for the packager to work in this direction "against" upstream and keep always all patches to use external libraries up-to-date.

As far as I can see, the most critical issue (Mono.Addins) is fixed. In the remaining list of f-spot provides (see below) only gnome-keyring-sharp is provided as a standalone package in Fedora.

So, would it be OK with you if we would limit the scope of this bug to the one remaining issue with the gnome-keyring-sharp library?


Best regards,
Christian

current list of provides of f-spot:

rpm --provides -q f-spot|grep mono
mono(BeagleService) = 0.0.0.0
mono(CDExport) = 0.0.0.0
mono(ChangePhotoPath) = 0.0.0.0
mono(Cms) = 0.0.0.0
mono(CoverTransition) = 0.0.0.0
mono(DBusService) = 0.0.0.0
mono(DevelopInUFRaw) = 0.0.0.0
mono(FSpot.Bling) = 0.0.0.0
mono(FSpot.Core) = 0.0.0.0
mono(FSpot.JobScheduler) = 0.0.0.0
mono(FSpot.Platform) = 0.0.0.0
mono(FSpot.Query) = 0.0.0.0
mono(FSpot.Utils) = 0.0.0.0
mono(FSpot.Widgets) = 0.0.0.0
mono(FacebookExport) = 0.1.0.0
mono(FlickrExport) = 0.0.0.0
mono(FlickrNet) = 2.1.5.15263
mono(FolderExport) = 0.0.0.0
mono(GalleryExport) = 0.0.0.0
mono(HashJob) = 0.0.0.0
mono(MergeDb) = 0.0.0.0
mono(Mono.Google) = 0.1.0.0
mono(Mono.Tabblo) = 0.3.3557.15267
mono(NDesk.Glitz) = 0.0.0.0
mono(PicasaWebExport) = 0.0.0.0
mono(RawPlusJpeg) = 0.0.0.0
mono(SemWeb) = 0.7.1.0
mono(SmugMugExport) = 0.0.0.0
mono(SmugMugNet) = 0.0.0.0
mono(TabbloExport) = 0.3.3557.15268
mono(ZipExport) = 0.0.0.0
mono(f-spot) = 0.6.1.2
mono(gio-sharp) = 2.14.0.0
mono(gkeyfile-sharp) = 0.0.0.0
mono(gnome-keyring-sharp) = 0.1.0.0
mono(gtk-sharp-beans) = 2.14.0.0
mono(libgphoto2-sharp) = 1.0.3557.15255

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I've fixed at least the problem for gnome-keyring-sharp in rawhide. 

At least when I've last checked some weeks ago, f-spot should not use a private library which is available in the system anymore. ;-)

So please don't hesitate to create a new bug report if this is still the case.

For now I'll close this bug as FIXED RAWHIDE.