Hi, On Mon, Oct 7, 2019 at 4:12 PM Ankur Sinha <sanjay.ankur@xxxxxxxxx> wrote: > > 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 scenario works for existing packages and experienced packager. When I am newbie working on a new thing, my workflow is more like: (1) put the sources in ~/rpmbuild/SOURCES/ (2) edit the spec (3) run rpmbuild -bp (4) browse buildroot (5) iterate steps 2-4 multiple times (6) run rpmdbuild -bb (7) browse buildroot (8) edit spec file (9) iterate steps 6-8 and 1-8 (10) once satisfied, run rpmbuild -bs (11) run mock I think possibility to run build partially stage by stage is extremely important for newbies. As well as discoverability of data, so you can easily browse through files, run local make commands directly in the BUILDROOT and so on. While it is not a recommended Fedora Packager workflow, it should be a recommended way to learn about RPM. > 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. Why are we trying to choose one over the other? Can not we have both workflows explained, detailed manual one with rpmbuild and fancy shortcut with fedpkg? > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > _______________________________________________ > 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 _______________________________________________ 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
