license of the binary policy
by Jilayne Lovejoy
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file
(as described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
) states, "The License: field refers to the licenses of the contents of
the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing,
it would be helpful to hear people's thoughts on the following:
1) how do you (package maintainers) interpret this policy in practice?
2) what further information/documentation about this policy would be
helpful?
3) should this policy be different, and if so, how?
4) any other related thoughts or observations
Thanks!
Jilayne
1 month
- 12
- 39
Help with packager tools installation/configuration
by Roberto C. Sánchez
Hello everyone,
I searched the list archives but could not find anything on this (nor
was a web search any help at all), so I am hoping that someone here can
help me figure this out.
I am going through getting started for packaging on Fedora, I have
created an account at Fedora Accounts, enabled OTP, and then become
stuck at the "Acquiring Kerberos Ticket" step of the Installing Packager
Tools [0] instructions.
In my case, I am trying to do all of this inside of a docker container:
docker pull fedora:latest
sudo docker run -t -i fedora:latest /bin/bash
sudo dnf install -y fedora-packager fedora-review
fkinit -u <my_fedora_accounts_username>
The only output I get is this:
Enter your password and OTP concatenated. (Ignore that the prompt is for only the token)
kinit: Invalid UID in persistent keyring name while getting default ccache
There is no prompt presented.
Does this mean that it is not possible to do packaging work from inside
a Docker container?
Regards,
-Roberto
[0] https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packa...
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
1 month, 1 week
- 2
- 2
Guiding co-dependent RPM packages to swap nicely
by Miro Hrončok
Hello.
Assume I have two "stacks" of RPM packages available:
postgresql16
provides postgresql-any version 16
conflicts with other postgresql-any
postgresql16-plugin
provides postgresql-any-plugin
requires postgresql16
conflicts with other postgresql-any-plugin
postgresql20
provides postgresql-any version 20
conflicts with other postgresql-any
postgresql20-plugin
provides postgresql-any-plugin
requires postgresql20
conflicts with other postgresql-any-plugin
On my system, I have postgresql16 and postgresql16-plugin installed and I want
to "upgrade" to postgresql20*.
Using my distribution package manager, I would want to run something like:
dnf swap postgresql16 postgresql20
However that will fail, as the package manager does not know I want to also
swap postgresql16-plugin with postgresql20-plugin.
Is there something I can do as a package maintainer to "guide" the co-dependent
swap case?
I was thinking something like:
postgresql20-plugin:
Obsoletes: (postgresql-any-plugin if postgresql-any != 20)
However that is not possible in RPM, "No rich dependencies allowed for this
type: Obsoletes".
Is there anything else?
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 month, 2 weeks
- 4
- 4
- ← Newer
- 1
- Older →