On 05. 11. 19 21:17, Stephen Gallagher wrote:
I'm sure there are other pain points and I encourage you to share
them. Please adhere to the guidelines about objectively measurable
issues, though.
M1.
For traditional packages, there was a consistent and easy way to find a spec
file for a given package on a given Fedora release.
Step 1. Figure out hat the source package is (e.g. repoquery --source)
Step 2. Go to src.fp.o or fedpkg clone the source pkg
Step 3. Switch branch to fN
For modular packages, I still don't remember how to do this, but I know it
requires more than 3 steps, to comply with the strict guidelines for complaints.
As an added problem, it is usually still possible to do the steps above and end
up with a spec file that is not what I have installe don my system (because the
package is modular without me realizing that).
As a side note, with the special package.cfg file, it is now getting more
complicated even with ursine packages. I however am also strictly against using
package.cfg to build on Fedora N from a different branch while not documenting
it in the fN branch.
M2.
For traditional packages, it was consistent and easy to find package
dependencies in Fedora. For a proven packager, Fedora Packaging Committee member
or generally for anybody doing a System Wide Change, being able to run queries like:
$ repoquery --repo=rawhide --whatrequires 'libpython3.8.so.1.0()(64bit)'
is trivial. Arguably, there are some quirks already (for example it doesn't
properly work with boolean (rich?) deps).
Witch modules, I still don't remember how to do this, but I know it requires
more than 1 easy repoquery over rawhide.
M3.
For traditional packages, it was consistent and easy to do a targeted rebuild
over a dependency bump. You repeat the previous step, gather source package
names, and do "fedpkg clone, rpmdev-bumpspec, git push, fedpkg build" for each.
With modularity, you need to figure out what modules even use your dependency,
how to update the packages in said modules, commit some empty commits into the
module and rebuild the module.
In cases where you need to do changes to accommodate some backwards incompatible
changes, you might get problems with modules that build on one Fedora, but ship
everywhere.
M4.
With traditional packages, we have processes to ensure that if a package is no
longer working, it eventually gets orphaned. Announcements are happening.
Dependent packages are informed.
If a module goes dead and potentially away, the dependent packages are not
automatically informed. And even if they happen to realize, it might not be easy
for them to unorpahn given module and start maintaining it, if they are not yet
familiarized with the technology.
(Let me know if anything needs more details, I'm writing this in a hurry before
I go somewhere.)
Disclaimer: I criticise the problems with the design and/or implemtatation of a
technology. I do not attampt to demoralize or offend any particular person,
group or project. If it sounds like it, note that it was not my intention. I was
always assuming this is obvious, but based on several e-mails I've seen
recently, I am rather being explicit.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
