[Bug 1763285] Review Request: libnma - NetworkManager GUI library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1763285



--- Comment #4 from Lubomir Rintel <lkundrak@xxxxx> ---
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@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




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux