HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Adam Williamson]

On Sat, 2012-10-27 at 06:45 +0200, Kevin Kofler wrote:
> Bill Nottingham wrote:
> > It causes problems for people who build things outside of chroots with
> > straight rpmbuild, though, if they need to ever build different things
> > with different buildreqs (even as test builds).
> > 
> > Admittedly, we like to encourage people to use mock, but people will still
> > hit this.
> 
> It also breaks building things directly from source, including as a 
> developer. We've had this issue with kdelibs3-devel vs. kdelibs4-devel, 
> where upstream didn't support parallel installation of -devel at all, and I 
> hacked things up to get that going exactly because of that. It would have 
> been really painful for developers of KDE software (including me!) to not be 
> able to have both -devel packages installed at the same time. You don't need 
> both for the same software, but a developer works on more than one piece of 
> software at a time.
> 
> And then there's also the case where something wants to build a subpackage 
> against, say, Qt 3 and another against Qt 4, we've had that case too (more 
> than once). And even one extreme case where gnash-klash was building the 
> Konqueror plugin (the KPart) against kdelibs 4 and the actual viewer 
> (embedded using XEmbed) against kdelibs 3, so it really needed both as a BR, 
> until the KDE 4 port of the viewer started working.
> 
> Conflicts should really only be a last resort, ESPECIALLY for libraries and 
> their -devel packages.

I've seen messy cases like that too. The kdelibs one sounds like a pain,
but for toolkits like GTK+ and Qt it seems a pretty established standard
that they're written to be parallel installable upstream because you'll
never get the whole world to change from one to the next overnight. So
those really aren't a problem.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net