https://bugzilla.redhat.com/show_bug.cgi?id=1813563 --- Comment #8 from Mattia Verga <mattia.verga@xxxxxxxxxxxxxx> --- (In reply to Antonio T. (sagitter) from comment #7) > (In reply to Mattia Verga from comment #5) > > > > > - Please, create a devel subpackage and include an symbolic link `libpasraw.so` pointed to `libpasraw.so.1.1` > > > The source code should generate/include header files too, and installed together the unversioned library. > > > Ask to upstream. > > Why? The package doesn't create an unversioned library and there's no need > > for it or for a -devel subpackage. > > This library is born to be a `private library`; it has been separated by > original software and it became a independent library now, must provide > -devel files for other project which use it in buildtime/runtime. > Althought, i don't understand yet what software really needs `libpasraw` > among that ones released by upstream. I've asked on the packaging mailing list if this is really mandatory... there are plenty of private libraries which don't provide their unversioned copy in a -devel subpackage and I can't find anything that says so in the guidelines. The other projects from the same author also don't require this lib at build time. > > > > > > - Use the patch to not install anything under `share/doc/libpasraw`, use only %doc to mark the documentation files. > > > > > > > - Linker flags are not used; use a patch like that attached and set the LDLAGS. > > Thanks for the patch > > > > > - This package provides a library earlier included in `libpasastro-1.2.*`; i guess it's better this way: > > > > > > new `libpasastro = 1.3.0-1` must > > > > > > BuildRequires: libpasraw-devel >= 0:1.3.0-1 > > > Requires: libpasraw%{?_isa} >= 0:1.3.0-1 > > > > > > meanwhile, `libpasraw = 1.3.0-1` will be always installed because needed by new `libpasastro >= 1.3.0-1`, > > > so it won't be ever **in conflict** with `libpasastro < 1.3.0-1` because they're never installed at the same time. > > I don't see the rationale for this. We have a packaging guideline that > > covers this case: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/ > > #_splitting_packages > > If the new package should be installable independently of whether the > > original package is installed, a versioned conflict is allowed > > It's true; but the original package (libpasastro), when updated, will not be > in conflict anymore with `libpasraw`. Since libpasastro-1.3.0 and > libpasraw-1.3.0 RPMs will be released together, i presume, then the conflict > `libpasatro-1.2* vs libpasraw-1.3.0` never exists. One could have libpasastro-1.2 installed and run `dnf install libpasraw` and that should end in a conflict (I'm not sure if with libpasastro-1.3 released dnf will update the conflicting dependency). But if one doesn't have libpasastro installed, they should not be forced to install it because it's listed as a requirement from libpasraw. -- 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 Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
