On Thu, Oct 29, 2026 at 12:47 PM Michael J Gruber <[email protected]>
wrote:
> while it's fall in some parts of the northern hemisphere and autumn in
> others, some thoughts on leaf packages, especially in language
> ecosystems.
SAD comes and goes, and is an issue that shouldn't be taken lightly,
but it doesn't necessarily mean one should give up on packaging either.
> Those thoughts are triggered by upstream changes in a python package
> that I maintain. I spent quite some time keeping it building in
> Fedora, and now trying things to follow the upstream changes according
> to our packaging principles, but I'm finally wondering:
>
> What for?
Proper packaging.
System package manager is the only package manager
that can actually manage the software stack bottom to top.
I'm yet to see a $LANG-ecosystem "package manager"
that can do a thing as basic as provide me a kernel header
corresponding to the version I'll be running,
yet people act as if they're something to be taken seriously.
The fact that $LANG package registries come with
NIH proof-of-concept tools that can pollute the system
with no regard to the underlying dependencies is unfortunate,
but it doesn't mean using it makes any modicum of sense (*).
(*) unless your major Linux distribution
comes with a package manager that's somehow even more anemic
than the $LANG-ecosystem package manager wannabees.
But one has to be Microsoft to pull such things off.
> In this case, and probably similar others, the upstream package is
> just a `pip install foo` away.
Shooting your own feet has never been easier, yes.
Doesn't really serve as a good argument to try it.
> This is what many users probably do anyway,
> because they use something like venv or pipx for dependency
> pinning so that their app keeps running with the same module
> independent of distro changes., and reproducibly.
This only holds water if said pinning covers their entire software stack.
At this point, whatever pinning tool they're running is their distro,
and I can only hope it's NixOS.
> It guarantees that you use the module as intended by upstream
> and can file bug reports there.
> So, what purpose does my python package serve? The install footprint
> might be leaner, well. Who cares nowadays?
I don't, and I cherish the ability to stay carefree
while my distro maintainer is the one doing the heavy caring lifting for me.
> If you're thinking about moving towards a containerised workflow,
> possibly switching to an image mode Fedora at some point, a good first
> step is to identify what you need in your base system (OS), and what
> is rather something "on top" that should live an independent life,
> independent of your base install (be it rpm/rpm-ostree/bootc), both
> technically and in terms of update cycles. Those things can live in a
> container, a flatpak, a venv etc.
>
> This is not a change proposal. It's just something I observed while
> pondering what to spend time on, some seasonal food for thought. New
> leaves are great to see in spring, but probably not the most
> worthwhile to spend time on in Fedora packaging, unless they serve a
> purpose that is achieved best as an rpm install. Same goes for
> existing leaves that go dry or outgrow their existing habitat,
> reaching for their own ecosystem.
>
> Cheers
> Michael
>
> FYI: If you're wondering - python-PyMuPDF is the package I mentioned
> above, but it's just one example.
> --
> _______________________________________________
> devel mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[email protected]
> Do not reply to spam, report it:
> https://forge.fedoraproject.org/infra/tickets/issues/new
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
