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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
