This request is superseded by
request 944131
(Show diff)
Overview
Request 943873 superseded
Fix broken Leap build and do some packaging improvements.
- Created by luc14n0
- In state superseded
- Superseded by 944131
-
Open review for
gnome-maintainers
Loading...
Request History
luc14n0 created request
Fix broken Leap build and do some packaging improvements.
gnome-review-bot accepted review
Check script succeeded
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:
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?
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 usesApache-2.0 WITH LLVM-exception OR NCSA
, even ourRPM Lint
doesn't recognize this exception nor the wiki/SUSE spreadsheet. This must be because SUSE doesn't ship/offerLLVM
, 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 thatSPDX
is already3.0
, yada yada yada. And drop the spreadsheet (as it was a workaround for the oldSPDX
that didn't cover many licenses in the past).Actually yeah, just the bottom part "Suse Additions".
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 forgtg
tarballs, but "GTG does not have any download files registered with Launchpad". So I'll fixcollab
'supstream-tarballs.txt
first before changing the spec.