https://bugzilla.redhat.com/show_bug.cgi?id=1763285
--- Comment #4 from Lubomir Rintel <lkund...@v3.sk> ---
Thank you.
(In reply to Matthew Krupcale from comment #3)
> A couple minor things I spotted after now building -gtk4 packages in rawhide
> and a bit more discussion on some points from the last review, and then this
> should be ready.
>
> > No, libnma doesn't obsolete libnma-gtk
>
> Okay, I suppose the network-manager-applet spec file libnm-gtk-devel package
> description was incorrect then.
>
> > I'll do that once the network-manager-applet package is updated and
> > libnm-gtk is actually dropped.
>
> It looks like libnm-gtk{,devel} was last built in F28, though. So is this
> not already essentially dropped?
Ah, yes. The point still stands though -- fedora-obsolete-packages should
obsolete it.
> > No, it's the presence of %files section or lack thereof that decides
> > whether a binary package is built. That is so by design.
>
> I only meant that the subpackages should not be defined in addition to the
> %files section being excluded. This was mainly just so it was clear for the
> reader only looking at the %package's what was built when, consistent with
> the %files. It's not a requirement as far as I can tell but only a
> suggestion.
I got that right. I'm not going to do that, it just seem to add noise.
> > Yes. This needs to get fixed upstream first:
> > https://gitlab.gnome.org/GNOME/libnma/merge_requests/5
>
> I believe you should go ahead and update the License: field and comment in
> the spec file (either around the License: field or in %files) about the
> shared/ license without having the COPYING.LGPL file included yet. In the
> next release you can include the file (assuming it's accepted upstream), but
> the license should still be correctly labeled.
Okay, done.
Note that this shouldn't have been necessary because the effective license was
correct:
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F
> > Yeah, it could be done, but it seems rather unnecessary to me at this point.
>
> I think it is good practice for three reasons:
> 1. Being noarch, the package can be built and installed anywhere
> 2. Reduces the repository size since the docs subpackages are not
> duplicated for each arch
> 3. Potentially reduces the download and install size for the user if docs
> are optional
>
> I don't believe this is a requirement, but I do think it's recommended,
> considering the size (>1 MB) of the documentation here.
No. This is a package that most people won't install, and is certainly not
going to be present in systems where 1 M matters at all.
> Issues:
> =======
> - mobile-broadband-provider-info only Required by -gtk4 but appears to be
> used by libnma as well
Fixed.
> - Spelling error in -gtk4-devel Summary: "exerimental" -> "experimental"
Fixed.
SPEC: http://v3.sk/~lkundrak/SPECS/libnma.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/libnma-1.8.26-3.fc32.src.rpm
--
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
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@lists.fedoraproject.org
