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:
~~~ $ rpmbuild --define "_sourcedir `pwd`" -bs package.spec ~~~ However, from this point, the mock should be used. There is no single reason to use rpmbuild, not even simplicity. Vít 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 -- [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]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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]
