Hi, On Mon, Oct 7, 2019 at 7:53 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Mon, Oct 07, 2019 at 05:38:51PM +0200, Aleksandra Fedorova wrote: > > On Mon, Oct 7, 2019 at 5:21 PM Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > > > > > > On Mon, Oct 7, 2019 at 3:11 pm, Ankur Sinha <sanjay.ankur@xxxxxxxxx> > > > wrote: > > > > 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. > > > > > > I don't agree. I can probably count on one hand the number of times > > > I've used rpmbuild directly in the past five years. fedpkg is much > > > simpler, and simple is what we should be promoting to new packagers. > > > > > > We can all have our own preferred workflow, nothing wrong with that. > > > But the newcomers guide should be as simple as possible. Learning > > > packaging is complex and the fewer tools that new packagers need to > > > learn, the better. > > > > I strongly disagree with your take on what simplicity is. There > > various kinds of simplicity: simple to execute, and simple to > > understand. > > > > Rpmbuild is verbose, it provides more details and information without > > wrapping it all in helpers, isolation layers and so on. Thus with > > rpmbuild you can easily get, what is going on. > > I think there's an analogy here to git: > git has low-level commands, and it _is_ useful to understand them, > particularly when one wants to learn how git internals work. > But it is not useful to teach people to use them. Instead, beginners > need to learn about git commit, git pull, git push, and so on. > We hide the lower-level details because the higher-level picture > is more important. > > Also, the replies in this thread show another issue: we teach people > to use rpmbuild, and even long-time packagers keep using such > workflows, because they are accustomed to them. This just confirms > that teaching a bad workflows early, just because it's "easier", is > doing a disservice to packagers. > > > I'd argue you don't want newcomers to copy-paste three cryptic > > commands and leave forever, you want to educate people on what they > > are doing. And cutting corners doesn't help in teaching. > > Right. So we should show the big picture (dist-git for sources, mock > for a pristine environment, koji for official builds, reproducibility, > reliability of builds, and how this all ties into a general philosophy). > If people need to figure out the details of some low-level command, > they will do it. I think we are talking about different things. It all depends on which question the doc is trying to answer. You are talking about "How do I contribute a package to Fedora". Then I agree, the doc should cover main infrastructure pieces and guide you how to get from source code to the rpm in Fedora repository. You don't need to dive into details of building an RPM here. But when the curios contributor asks "How do I create an rpm?", this is a different kind of story. And "run fedpkg build" is a bad answer to it. I did a Fedora Classroom on RPM several years ago. And the main concept I tried to show there is the concept of sections in RPM spec file (setup, build, install, check..). rpmbuild exposes those stages to the user, so that you can touch and feel them, play with the outcome. You can literally see the buildroot directory and how files are moving around once you execute the next step. This is extremely helpful for newcomers who are struggling to get even the setup section right at first. If I were writing the doc on RPM now, I would have two parts on it. First - detailed explanation with step-by-step rpmbuild commands, and then a "shortcut" section with "And in Fedora we recommend you to do this and that". This would address the "teaching a bad workflows" concern. In the end it shouldn't be one or the other, it should be both, cross-linked. -- Aleksandra Fedorova bookwar _______________________________________________ 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
