>>>>>>> "AL" == Alex Lancaster writes: [...] AL> https://bugzilla.redhat.com/show_bug.cgi?id=442343 AL> 1) there are no binary .DLLs in the package that don't have AL> associated source, so legally OK >>>>> "TK" == Toshio Kuratomi writes: TK> Yep. I didn't list f-spot as binary in my message. I know, I think Jesse thought so when we were discussing it on IRC. AL> 2) most of the provides listed by Toshio in his original message AL> appear to part of f-spot itself (like semweb, FlickNet etc) and AL> *do* have associated source TK> Uhm.... They do have source, but I don't think they are part of TK> f-spot. I could be wrong but: semweb: TK> http://razor.occams.info/code/semweb/ flickrNet: TK> http://www.codeplex.com/FlickrNet Yes, in discussion with the Debian maintainer on #f-spot, it does appear that they do have upstreams, but nothing else in Fedora yet depends on them. Ultimately, yes they should be packed separately if possible. TK> I googled everything that I specifically wrote into my message and TK> looked to see if the sources had corresponding filenames or other TK> indications of matching the library that was found. AL> 2) of the DLLs that could be potentially provided by other packages AL> we have: AL> /usr/lib/f-spot/libgphoto2-sharp.dll (effectively this is upstream AL> for libgphoto apparently, it could be patched to use system one) TK> This should be fixed. Jesse didn't report any problems with it TK> currently, though. Yes, again in discussion with the Debian maintainer it appears that newer f-spot's will include this ability. It's a little unclear because the official libgphoto2-sharp apparently pulls from the f-spot SVN, if I understand the f-spot maintainer correctly. AL> /usr/lib/f-spot/Mono.Addins* (a patched version of upstream) TK> This one is the problem child as it's causing issues for other TK> packages that require mono(Mono.Addins).... rpm is satisfying the TK> dep with f-spot which doesn't actually work for the packages that TK> need mono(Mono.Addins). Yes, this is now done in the latest build on f-spot: http://koji.fedoraproject.org/koji/buildinfo?buildID=46254 again got a patch thanks to the Debian maintainer (who apparently has had to go through some of the same hoops as us with f-spot, since the f-spot maintainer has only recently included the ability to link against some of the system libs). AL> /usr/lib/f-spot/Tao.* (there is an upstream apparently, but it's AL> not yet packaged by Fedora and not installed in gac yet anyway) AL> /usr/lib/f-spot/gnome-keyring-sharp.dll (there is upstream, not yet AL> packaged in Fedora, and not yet stable to be in gac apparently) TK> If this package were undergoing review in its current state it TK> would not be able to go into the repo until these dependencies TK> were packaged. Still, by itself, it's not a reason to yank it for TK> F-9. It could be a reason to remove them from the start of the TK> F10 devel cycle, though. Right, keep it in F-9. I think everything should be able to be packaged separately, so I see no reason to remove it from F-10, it needs some time to allow the other deps to be packaged. Remember this is hold over from the pre-Merge days, and has it's own merge review somewhere, and we're not necessarily yanking those because the merge reviews aren't finished or have problems. AL> So the only files that conflicts as far as also being provided by AL> other packages appears to be Mono.Addins*.dll. This should AL> probably be fixed (and Tao and gnome-keyring-sharp packaged) very AL> soon, but based on this analysis I don't see any need to yank the AL> package itself from f9-final as it appears to legally OK. TK> I think Jesse was noting the problem with tomboy and TK> mono(Mono.Addins) as the reason to yank. If the choice were to TK> have a working tomboy and a removed f-spot or vice-versa I'd have TK> a hard time figuring out which was the more necessary application. TK> If someone adds the Debian patches for f-spot to fix this by F-9 TK> that will be the best outcome overall. As I said above, this is done now, so the tomboy/f-spot conflict shouldn't be a problem anymore. I have to build mono-addins to fix a potential problem with addins disappearing from f-spot. But once done, they can both be tagged f9-final. A. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
