Re: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux