planning to orphan python-django (and a couple of dependent packages)
by Matthias Runge
Hello there,
you may or may not know, I have been maintaining python-django for quite
some time in the past, some time as part of my job. My role changed and
I really can not dedicate Django the time it deserves. I am looking for
someone or persons willing to take
- python-django
- python-django-angular
- python-django-appconf
- python-django-authority
- python-django-compressor
- python-django-contact-form
- python-django-debug-toolbar
- python-django-haystack
- python-django-mptt
- python-django-nose
- python-django-notification
- python-django-pagination
- python-django-pipeline
- python-django-piston
- python-django-pyscss
- python-django-rest-framework
- python-django-reversion
- python-django-robots
- python-django-tables2
- python-django-tagging
Matthias
1 year, 5 months
- 2
- 2
Splitting alternative Python packages into subpackages, e.g.
python3.11{,libs,devel,...}
by Tomáš Orsava
Hi Python-devel,
we are considering splitting the alternative Python versions from a
single-package format (e.g. python3.11) to multiple subpackages (e.g.
python3.11{,-libs,-devel,-tkinter,-test,-idle}). We do this already with
the main `python3` package: it requires less disk space to install and
speeds up download times, because you can chose which bits are important
to you. For example, if you decide you don't need python3-tkinter, you
save yourself ~18 dependent packages leading to a total savings of
~20MBs, while skipping python3-test saves you further ~10MBs.
What do you think?
The push came from [BZ#2063227] where the reporters would welcome to
have a smaller python3.11 package for containers and VMs for local
testing, CI purposes and more.
This would be a larger amount of work, so our initial reaction was
hesitant. We'll have to change the already complicated spec file %bcond
logic, and adjust the ecosystem to work with the new subpackages. For
example tox would need to Recommend `python3.11-devel`, as `python3.11`
would bring in only the bare interpreter. And of course a thorough
integration testing would be in order.
However, we already do separate subpackages for alternative stacks in
Enterprise Linux (CentOS /Stream, RHEL, EPEL) and as a general rule we
consider it good to have fewer differences between Fedora and EL. This
helps to test things earlier, and there are fewer surprises in user
experience. So perhaps the effort in doing this would be well spent.
To cut down on the amount of work, we're considering changing only the
`python3.11` package (and any future newer versions) right now. If later
we consider it worth it, we could switch the older alternative
interpreters as well, or we might let them die out as they are.
We're currently in the brainstorming stage, so you're feedback is welcome.
[BZ#2063227] https://bugzilla.redhat.com/show_bug.cgi?id=2063227
All the best,
Tomáš
1 year, 7 months
- 4
- 5
- ← Newer
- 1
- Older →