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.AddinsJK> 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.
Uhm.... They do have source, but I don't think they are part of f-spot. I could be wrong but: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
semweb: http://razor.occams.info/code/semweb/ flickrNet: http://www.codeplex.com/FlickrNetI 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 bepatched 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 FedoraIf 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.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 tobe in gac apparently)
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.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.
-Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list