Ease licensing maintenance and
Hi everybody,
after discussion with jreznik, tcallawa and pchibon about licensing in
RPMs, I've decided to create a common package for licenses which allow
separate shipping from the sources/binaries.
Currently the developer needs to package each such license for each
(sub)package manually and the end user needs to read it through every
time new version is installed. Because the license mentioned in the tag
License: doesn't correspond to the real license present in the RPM
(e.g. GPLv3 with exceptions can refer to some customized version of
GPLv3 and therefore this license is indistinguishable from other GPLv3
with exceptionss in the Good Licenses matrix).
I'd like to address this issue like Arch Linux does. I.e. provide a
common set of licenses (allowed to be shipped separately) which could be
used by the maintainer on a voluntary basis to simplify things (for both
him and the end-user). Such package contains also properly formatted
licenses and serve as an official wording. Arch linux also solves the
problem of customized versions of licenses using custom: prefix before
each name of such license and in such case the maintainer is forced to
include the customized version and two licenses with the same identifier
and the custom: prefix are not comparable (i.e. end user can't assume
custom:X is the same as custom:X from another package). This also means
that rpmlint would need to be updated.
As a side-effect we'll also spare a few megabytes of bandwidth and disk
space :). Maintainers would need to check the license only once when
creating the first spec file and then just when some change to license
file(s) occur in upstream (this is easy and we do it already). But how
many maintainers could simplify their %files section in spec files? Some
statistics from f19 give us an answer:
repoquery --repoid fedora --repoid updates --qf='%{license}' '*' | sed
-r 's/ *(and|or) */\n/g' | sed -r 's| *[()]* *||g' | sort | uniq -c |
sort -n
I've matched those licenses present more than 100 times with licenses
present in the attached spec file and did comparison:
# non-aggregatable licenses (majority consists of MIT, BSD, (L)GPLx with
exceptions, ASL and Public Domain)
grep -Ev '^\* ' del/lic04.hand_checked | awk '{ x+=$1 }END{print x}'
27144
# aggregatable licenses
grep -E '^\* ' del/lic04.hand_checked | awk '{ x+=$2 }END{print x}'
43137
The aggregatable licenses make 61.4% out of all mostly used licenses
(100+). Please note, that it's much more difficult (for end user or
reviewer) to find out if the License: tag in spec file matches the
bundled LICENSE files than just having the tag and nothing in the %files
section. I've come across this issue when doing package reviews - on 7
reviews 1 such bug - that's probability 1/7 which is so high I'd rather
not know it.
In a few days I'm leaving for vacation, but I wanted to release this
package yet before I'm inaccessible.
Please share your experience and review the attached licenses package.
Feel free to add other possible licenses from
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing .
Kind regards,
-- Jan Pacner
licenses-1.0-1.fc20.src.rpm
Description: application/rpm
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Koschei - continuous rebuilds for packages
Hi Kevin, Not impossible, but we would probibly want it running inside Fedora Infrastructure and need to be careful security wise. That is also a part of our design. Kind regards, -- Jan Pacner -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Koschei - continuous rebuilds for packages
Hi Michael, Detecting soname bumps and doing real rebuilds instead of scratch build should be possible. Koschei could automatically start rebuilding dependent packages AFTER you update the library in rawhide. That's the goal. But if you want to know what will break before you do the update then it will be more complicated, because Koschei will need to manage separate Koji tags and obviously first get permission to do so and I'm not sure whether relengs would be willing to make this happen. That would be convenient - at least for critical-path packages. Anyway, lets ask lkocman (CC) about Koji tags. And for both solutions Koschei would need to get provenpackager-like priviledges to be able to bump the release. Regarding remote interface - there is none, but I can make it as soon as it's needed. I didn't have use case for it yet. Great to hear it. Thank you. Kind regards, -- Jan Pacner -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Koschei - continuous rebuilds for packages
Hi Petr, The rebuilds run in koji. You cannot get scratch build into koji build root. You would need separate koji build target tag for that. I understood that Koschei does it anyway (to be able to rebuild the dependency subtree). Either way, it doesn't sound problematic to create temporary tags (although I'm not sure about performance penalty). -- Jan Pacner -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Koschei - continuous rebuilds for packages
Hi Michael, it sounds like a way how one could automatically handle library so-bumps in rawhide. Idea discussed with hhorak, jzeleny, pingou and others was to bump the library package, rebuild the dependency tree depending on this library and if some of them fail, notify it's maintainer(s) and the bumped library owner as well (email CC should be sufficient). If it doesn't fail, we can automatically immediately rebuild it in non-scratch environment. This'll save so much time and effort and also suppress the need for finding maintainers of the library and notifying them about the so-bump. So the question regarding Koschei is if one could schedule one-shot build of a library package (preferably from CLI) and if one could get the result of such run on CLI (allowing automation). The CLI tool would be just thin wrapper around remote interface (JSONRPC/XMLRPC/...). Do Koschei have such interface? Kind regards, -- Jan Pacner -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unannounced soname bump: libdbi?
Hi, that was my mistake. Now both libdbi and libdbi-drivers are in new version in rawhide. -- Jan Pacner On 01/21/2014 09:53 PM, Ville Skyttä wrote: Hi, Looks like yet another unannounced soname bump has occurred in Rawhide, this time libdbi. If there was an announcement, I haven't noticed it, and neither apparently have maintainers of dependent packages, and they haven't been addressed by anyone else either except for rrdtool which is currently being rebuilt. libdbi owners, comments? Please observe https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages Affected packages include at least: Io-language collectd-dbi gammu-libs gnucash python-gammu rrdtool rrdtool-lua rsyslog-libdbi syslog-ng-libdbi ulogd-libdbi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
