Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=708765 --- Comment #30 from Mario Sanchez Prada <msanchez@xxxxxxxxxx> 2011-06-02 11:17:19 EDT --- (In reply to comment #29) > [...] > I think you could also package a Git snapshot of flicksoup and use it instead > of the bundled library. In this case, all changes to the bundled library > should of course be pushed to the flicksoup repo so that both source pools > are in sync and future updates work smoothly. Hmmm... the more I think about it the more I regret having started with flicksoup as a separate thing in the first place. I should have started everything together and split it later on, then we wouldn't have this problem now... :/ Currently flicksoup files inside of frogr are not on sync with those in gitorious (frogr's files are more recent) and they probably will change a little bit more during the development of frogr 0.6, specially in those functions related to proxy support. > If the FPC doesn't grant an exception, this is probably the only alternative. If the Fedora Packaging Comitee granted that exception that would be awesome. As I said, I'm open to (temporarily at least) removing the git repository of flicksoup in gitorious, and I'm also open, if bundling a static library in frogr is a problem (as I understand from your words), to merge even more those files in src/fliksoup with frogr, so they would be compiled just through the same set of files in the SOURCES variable, in src/Makefile.am. That way, there wouldn't be anymore a libflicksoup.a frogr would link against, just the source files as they are, avoiding the problems with Fedora packaging, if I got it right. In the future, if I (or anyone else) manage to get the right timespan to make flicksoup an independent package out of frogr, we would just remove those files and set the dependency. But all this, when it comes to releasing frogr 0.5 in fedora, would mean that such an exception should be granted. Or well... if such an exception was not granted we could also release frogr 0.5.1 with those modifications in place, in case you agree is a good idea If this idea (remove the libflicksoup.a from frogr) was feasible, I'd say is the best way to go. And if keeping the flicksoup files inside of frogr with the LGPLv3 license was not a problem for Fedora, then it would be perfect. > (In reply to comment #26) > > if I released it > > now, I couldn't promise I wouldn't break API/ABI in the next releases > > That shouldn't be too much of a problem as long as you bump the soname and > soversion accordingly. Yeah, I know, but the problem is other... more related with me feeling confident and comfortable enough to releasing the library separately. And because one reason of another the truth is that I still do not feel like it... Btw, just in case you wonder, do not worry about me perhaps disliking the idea of dropping the flicksoup repo from gitorious... actually that wouldn't be that bad for me, since it would free me from the burden of having to keep two copies of the same file set on sync, and I could always re-open it in the future when I feel confident enough to propose flicksoup as an independent package :-). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review