Overview
7+- Add hicolor-icon-theme build requirement to avoid ownership of 8+ hicolor directory by the package;
Not really correct; in this case probably close to impossible to fun into an issue, but any BR for 'ownership hack' is wrong.
Consider this case:
- PKG A has BuildRequires FOO in spec to not have to own /usr/blabla, and install as file into /usr/blabla/blubb
- PKG A has no runtime dep on FOO (same situation as you created in gtg)
When a user install A, then uninstalls A, the directory /usr/blabla remains back, as nothing ever owned it, so package uninstall is responsible to remove it.
Long story short: BR for file ownership without runtime dep is wrong :) (and more expensive in the dep chain tree rebuild, as a change to hicolor-icon-theme now triggers a rebuild of this package on rebuild=direct mode)
I was hoping for some automagic RPM/SUSE thing here.
This rases the question then: shouldn't every package that installs icons (and similar data) own the directory they use to install stuff, so whenever the package gets uninstalled so does their data?
9+- Replace "+" with "-or-later" to GPL 3.0 license tag to comply with 10+ openSUSE's License naming scheme;
I don't like the 'blaming on openSUSE License naming scheme'. it is not defined by openSUSE, but rather SPDX; GPL-2.0+ was deprecated in favor of GPL-2.0-or-later in SPDX 3.0 and openSUSE follows SPDX license formats (you see, it is NOT openSUSE's License naming scheme)
Yeah, I didn't realize until now that it sounds like I'm blaming openSUSE. I could clarify that with: to comply with openSUSE's License name use which follows SPDX short name formats.
Or something like that. Does it sound better?
I'd just do:
"Update license tag to SPDX-3.0 format: change GPL-3.0+ to GPL-3.0-or-later"
Make it simple. I like it better.
I'm thinking about updating the wiki to point to a sub-page showing the "extra" short names that SPDX lacks from that spreadsheet (and keep this spreadsheet at the end too), so things get clearer. I'm gonna make a quick stub to show what I mean.
you mean something like
https://github.com/openSUSE/obs-service-format_spec_file/blob/master/README.md
?
No, I mean having this new sub page where only the short names of licenses not covered in the SPDX 3.0 page like SUSE-* ones, etc. All from the SUSE spreadsheet currently in the wiki.
This SUSE license mapping spreadsheet shown in Spec Files inside Packaging Guidelines is a bit out of date. There we can see "VIM | SUSE-Vim" but SPDX has now the Vim license. "JSON | SUSE", same thing.
Another case that's not covered anywhere I know (maybe there's a bug, I haven't searched the bugzilla yet) is LLVM that uses Apache-2.0 WITH LLVM-exception OR NCSA, even our RPM Lint doesn't recognize this exception nor the wiki/SUSE spreadsheet. This must be because SUSE doesn't ship/offer LLVM, I reckon, so it must felt through the cracks.
So, summarizing, in the main page (Packaging Guidelines, under Spec Files) it would show some examples of popular license short names, and tell openSUSE follows SPDX (just like it's being done already) but emphasize that SPDX is already 3.0, yada yada yada. And drop the spreadsheet (as it was a workaround for the old SPDX that didn't cover many licenses in the past).
Actually yeah, just the bottom part "Suse Additions".
11+- Append #/%{name}-%{version}.tar.gz to the Source tag for tarball
12+ name expansion rather than just v%{version};
Not wrong, but you will hate yourself for it when using osc collab up :)
So Collab is not aware of this yet? Is it using its own way/script to download GH stuff?
collab has does not parse the spec file to find thee location for tarballs; it simply inspects websites (download.gnome.org, github assets) and uses the links as they are there. Then updates the Source: tag according to what it downloads
Duh! That's right. I knew that already but my brain doesn't function properly using a cell phone.
I see collab parses Launchpad for gtg tarballs, but "GTG does not have any download files registered with Launchpad". So I'll fix collab's upstream-tarballs.txt first before changing the spec.
Request History
luc14n0 created request
Fix broken Leap build.
gnome-review-bot accepted review
Check script succeeded
dimstar accepted review
dimstar approved review
dimstar accepted request
xin+
