https://bugzilla.redhat.com/show_bug.cgi?id=1531955
--- Comment #9 from Alec Leamas <leamas.a...@gmail.com> ---
(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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
