It seems that the biggest issue with the documentation you have
is the `fedpkg` and I agree, we should not recommend it. Instead
of `fedpkg`, this should be used to create the SRPM:
However, from this point, the mock should be used. There is no
single reason to use rpmbuild, not even simplicity.
Dne 07. 10. 19 v 16:11 Ankur Sinha
napsal(a):
On Mon, Oct 07, 2019 12:56:51 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 07, 2019 at 12:13:34PM +0100, Ankur Sinha wrote:
On Mon, Oct 07, 2019 12:16:28 +0200, Vít Ondruch wrote:
If you would like to have rpmbuild mentioned in the docs, then mock should be
mentioned as well.
mock is mentioned in the "Create an hello world rpm" doc:
https://docs.fedoraproject.org/en-US/quick-docs/create-hello-world-rpm/
But, "make a package" on the "Join the package collection maintainers":
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Make_a_Package
links to the top level "Creating rpm packages" document which does
things in terms of fedpkg:
https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/index.html
Plain rpmbuild has all the wrong defaults. It caters to the 90's
layout of ~/rpm/{SPECS,RPMS,SRPMS,whatnot} which leads to pointless
file naming conflicts between packages, and is generally incompatible
with the idea of version control. It also makes it hard to account and
clean up disk space, since you can never know when exactly a file in
one of those global directories is stale.
See, all of these are issues---defaults, cleanups, and so on---that
package maintainers may face---but they don't have to use these at all.
They can limit themselves to using `fedpkg`.
Other rpm tools also generally have no concept of "this directory is a
package", so one must always specify the exact file to operate on
(either .spec, or .src.rpm).
At least when saying 'fedpkg build' you
can't specify a wrong version, while with
'rpmbuild -bb foo-3:232-5-fc30.point11.src.rpm' is it more than easy,
esp. when relying on shell history.
I have honestly not used `rpm -bb` in a long time, if ever. The workflow
always is:
- edit the spec
- put the sources in ~/rpmbuild/SOURCES/
- run `rpm -ba` on the spec.
- IIRC, the old docs mentioned `rpm -bs` and then using `mock`---thus
exposing newbies explicitly to `mock` and the concept of clean
chroots.
This is simple enough for newbies. Using `fedpkg` isn't always,
especially given that it aims to work both in dist-git and outside it.
Newbies don't even know what dist-git is when they start, and at times
they assume they can use the dist-git method and are extremely confused
when it doesn't work (what is the lookaside cache? do I need the
sources file, and how do I write it? why won't `fedpkg build` just do
it---why must I use `local` or `scratch-build`? `fedpkg module-build`,
what's that?)
All those things can be solved, but each of them is annoying,
confusing, and an easy source of errors. Exactly what you don't
want to expose newbies to.
Didactically, I think going through the basics step by step does serve a
purpose, though.
fedpkg manages to sidestep many of those issues. Hence, I think
it is very much appropriate to teach new packagers this workflow.
I agree that it makes it easier for package maintainers. I'm arguing
that it shouldn't be the first tool that newbies are exposed to. They
shouldn't just learn how to use `fedpkg` and not touch on how `rpm`
works.
I.e., newbies need to learn two skills:
- how to use rpm and build rpms
- how to use the Fedora build system
The first is independent of the second. The second changes and evolves
as we tweak it. Only learning the second is a bad idea---some idea of
how these tools work "under the hood" is quite important for a complete
understanding of the pipe line.
If anything, we should make it easier to use fedpkg even without
any integration with the fedora infrastructure. IMO, anything
which starts with rpmdev-setuptree is doing the reader a disservice.
I disagree. `fedpkg` is the Fedora tool for interacting with the build
system----rpms, modules, flatpaks and containers in the future if not
already (I don't know). "making RPMs" and "making RPMs for the Fedora
build system" remain two different skills. The second depends on the
first, but the first is independent of the second.
So I guess I am arguing that while the "new package for existing
maintainers" remain at the `fedpkg` level of doing things, the "join the
package collection maintainer" page for newbies, who should not be
assumed to have prior knowledge about rpm, should start at the
`rpmbuild` level and promote them to `fedpkg` when they reach the
"import to SCM" steps.
_______________________________________________
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
