Golang package naming for packages from sourcehut
by Gergely Polonkai
Hello,
I’m about to create a package for getopt[1], which is hosted on
sr.ht. For this, the import path looks like git.sr.ht/~sircmpwn/getopt
(note the tilde before the username). Using the GitHub username in
package names is straightforward (as stated in [2]), but this tilde
might cause problems.
However, given that all usernames on Sourcehut begins with a tilde, i
guess the correct package name here would be on of these:
- golang-sourcehut-sircmpwn-getopt
- golang-srht-sircmpwn-getopt
Am i correct assuming this?
Also, which one should i use? Based on the service name it should be
“sourcehut”, but based on the service’s domain it should be “srht”.
Best,
Gergely
[1] https://git.sr.ht/~sircmpwn/getopt
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_naming
7 hours, 56 minutes
Directory ownership of %{_datadir}/icons/hicolor
by Otto Urpelainen
Hello packagers,
I have problems interpreting Packaging Guidelines section File and
Directory Ownership [1] for icons application place in
%{_datadir}/icons/hicolor. I ran into this during package review for
dosbox-x [2], but I think the issue is more general than that, because
many applications add their icons to the (default, fallback) hicolor theme.
So the package places application's icon to
%{_datadir}/icons/hicolor/scalable/apps/dosbox-x.svg. From the
guidelines, it is clear that for all directories in the chain, one of
the following has to be true:
1. Package owns the directory
2. A dependency package owns the directory
3. _filesystem_, _man_ or "other explicitly created -filesystem
package" own the directory
Item 3 takes care of %{_datadir}/icons part, because that is included in
_filesystem_. The remainder hicolor/scalable/apps is unclear for me.
Method 1 could be used. But there is also package _hicolor-icon-theme_.
Is that package an "explicitly created -filesystem package", so method 3
could be used? That would feel natural, because hicolor is the fallback
theme that must exist according to freedesktop.org specification.
Related but separate question about the guidelines: Section Unowned
Directories:Inaccessible Directories [3] discusses a problem that is
only relevant to Fedora < 9 and RHEL < 5.3. It does not really contain
any information that is relevant today. Should that section simply be
removed?
Otto
[1]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_dire...
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1919639
[3]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirector...
1 day, 21 hours
How to automatically handle Python namespace packages (e.g. in %pyproject_save_files)
by Miro Hrončok
Hello Pythonistas.
I'd like to be able to automatically handle Python "namespace" packages from our
packaging macros.
The problem:
Several Python packages share a "namespace", let's take an artificial example
with food.spam and food.eggs Python packages.
1. the Python packages both have site-packages/food
2. sometimes such packages also both have site-packages/food/__init__.py
(usually empty or mostly empty, but with different mtimes etc.)
On RPM level, this means:
1. %{python3_sitelib}/food can be co-owned
OR it can be in an artificial python3-food(-filesystem) package [0]
OR it can be in an existing package that is always present [1]
2. %{python3_sitelib}/food/__init__.py and
%{python3_sitelib}/food/__pycache__/__init__.*.pyc
will conflict if present in multiple packages,
they need to be removed or shared from the python3-food(-filesystem) package
I want to solve this once for all, define the best practice, document it in the
packaging guidelines and possible automate this in %pyproject_save_files [2].
My current idea is:
- sharing directories is safe and easy,
let's do that instead of artificial packages (those are hard to automate)
- namespace packages should not need __init__py with modern Python 3,
let's discourage that
- If needed for %check, the __init__.py + .pyc should be %ghosted [3]
And with the %pyproject_save_files automation, let's say that if
%pyproject_save_files is used with a dot:
%pyproject_save_files food.spam
The dots separates a namespace and:
- food folder is co-owned
- food/__init__.py + .pyc is %ghosted if found, possibly with a warning
- any other Python files in food/ except spam.py or spam/ are not included
In case of nested namespaces (I have never seen that in reality), this can be
applied recursively.
Since %pyproject_save_files takes globs, I propose we split the argument on dot
and treat each part as a separate glob.
An alternate proposal which is less magical, more explicit about the "namespace"
situation but less explicit about what to include requires a special namespace flag:
%pyproject_save_files -N food
This says: Include food supackages, but food is a namespace package:
- food folder is co-owned
- food/__init__.py + .pyc is %ghosted if found, possibly with a warning
- all other Python files in food/ are included
Alternatively, this can be combined together somehow:
%pyproject_save_files -N food spam
But I don't like that.
Thoughts?
[0]
https://src.fedoraproject.org/rpms/python-jaraco-packaging/blob/rawhide/f...
[1]
https://src.fedoraproject.org/rpms/python-sphinx/blob/rawhide/f/python-sp...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1935266
[3]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 days, 20 hours
