>>>>>>> "AL" == Alex Lancaster writes:
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:
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
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:
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.
fedora-devel-list mailing list