saving f-spot (was Re: Mono Package audit)

[Toshio Kuratomi]

Alex Lancaster wrote:
>>>>>> "AL" == Alex Lancaster  writes:
> 
>>>>>> "JK" == Jesse Keating  writes:
> JK> On Wed, 2008-04-09 at 19:08 -0700, Toshio Kuratomi wrote:
>>>> .. _f-spot: At least, dbus-sharp, libgphoto2-sharp,
>>>> gnome-keyring-sharp, Tao, google-sharp, FlickrNet, semweb,
>>>> (dbus-sharp-glib?), Mono.Cairo, Mono.Addins
> 
> JK> Seems this one got missed.  I'm still trying to find something
> JK> from spot related to this package, but right now things aren't
> JK> good.  It hasn't been built in a while, and it provides a bunch of
> JK> things that other mono packages are now looking for at a system
> JK> level, so new system level mono packages aren't being brought in
> JK> correctly.
> 
> JK> Somebody want to tackle f-spot please (so that I don't have to
> JK> block it from the distro for F9 launch)
> 
> AL> Here is the corresponding bug:
> 
> AL> https://bugzilla.redhat.com/show_bug.cgi?id=442343
> 
> OK, I did an audit of the package and discussed things with the folks
> on #f-spot on irc.gnome.org and I've summarised my findings on:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=442343
> 
> Basically:
> 
> 1) there are no binary .DLLs in the package that don't have associated
>    source, so legally OK
> 
Yep.  I didn't list f-spot as binary in my message.

> 2) most of the provides listed by Toshio in his original message
>    appear to part of f-spot itself (like semweb, FlickNet etc) and
>    *do* have associated source
> 
Uhm.... They do have source, but I don't think they are part of f-spot. 
  I could be wrong but:
   semweb: http://razor.occams.info/code/semweb/
   flickrNet: http://www.codeplex.com/FlickrNet

I googled everything that I specifically wrote into my message and 
looked to see if the sources had corresponding filenames or other 
indications of matching the library that was found.

> 2) of the DLLs that could be potentially provided by other
>    packages we have:
> 
> /usr/lib/f-spot/libgphoto2-sharp.dll  
>  (effectively this is upstream for libgphoto apparently, it could be
>  patched to use system one)

This should be fixed.  Jesse didn't report any problems with it 
currently, though.

> /usr/lib/f-spot/Mono.Addins* 
>  (a patched version of upstream)

This one is the problem child as it's causing issues for other packages 
that require mono(Mono.Addins).... rpm is satisfying the dep with f-spot 
which doesn't actually work for the packages that need mono(Mono.Addins).

> /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)
> 
If this package were undergoing review in its current state it would not 
be able to go into the repo until these dependencies were packaged. 
Still, by itself, it's not a reason to yank it for F-9.  It could be a 
reason to remove them from the start of the F10 devel cycle, though.

> So the only files that conflicts as far as also being provided by
> other packages appears to be Mono.Addins*.dll.  This should probably
> be fixed (and Tao and gnome-keyring-sharp packaged) very soon, but
> based on this analysis I don't see any need to yank the package itself
> from f9-final as it appears to legally OK.
> 
I think Jesse was noting the problem with tomboy and mono(Mono.Addins) 
as the reason to yank.  If the choice were to have a working tomboy and 
a removed f-spot or vice-versa I'd have a hard time figuring out which 
was the more necessary application.  If someone adds the Debian patches 
for f-spot to fix this by F-9 that will be the best outcome overall.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080415/9c476305/attachment.sig>