https://bugzilla.redhat.com/show_bug.cgi?id=1531955 --- Comment #9 from Alec Leamas <leamas.alec@xxxxxxxxx> --- (In reply to Antonio Trande from comment #8) > > - seqan2 obsoletes seqan without providing seqan. > > It's not needed. seqan2 and seqan must coexist for now. Well, if they should coexist the Obsoletes: is obsolete(sic!). Perhaps you just should drop that? > > - seqan2-devel does not depend on seqan2 = %{version}-%{release}. > > Why? https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package > > - A binary zip file is present in the examples package. No comment on this? > > - Several bundled files/directories in util/py_lib/seqan/dox/tpl/lib and > > include/seqan/stream. Please either remove these in %prep and/or bundle > > properly using Provides: bundled(...) > > I have already said why it's not needed. GL says something else: Bundled libraries must be treated as such: https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries Not bundled code must be removed in %prep: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Treatment_of_Bundled_Libraries > And why 'include/seqan/stream'? Some of those headers carry specific licenses and comes from other projects. I don't have the code at my current box, and the srpm link is broken (could you please fix?) so I don't have the details. That said, several headers are definitely bundled code. > > - The License field comment does not match the actual file licenses in the > > sources. My proposal: Remove in %prep, add a text document describing > > the licensing situation. > > https://bugzilla.redhat.com/show_bug.cgi?id=1531955#c4 This is not about the overall License: tag, it's about the comment. That said, note that the GL strongly recommends using an AND type of licensing in cases like this https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios But either way, a clarification of what code has what license is needed, even if you choose to go for a common license. I might wan't to refer to fedora-devel before using a common license, though. My gut feeling somewhat bad. > > - There are tests available. Why are these not run? > > Tests are performed in %check. Indeed, my bad. Sorry for the noise. > > - The pkg-config file is not shipped with the -devel package for no obvious > > reason. > > - Likewise for seqan-config.cmake. > > > > Why? Is it indispensable? That's certainly subjective. But using my version of common sense, if upstream makes efforts to create .pc and cmake macro files we need a compelling reason to *not* include them. After all, they save a lot of work for those who use the package. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
