On Sun, 20 Dec 2020 at 00:23, Pavel Raiskup <praiskup(a)redhat.com> wrote:
On Thursday, December 17, 2020 8:05:40 PM CET Ben Cotton wrote:
>
https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
>
> == Summary ==
> This change should enable an opt-in spec file preprocessor in Fedora
> infrastructure for the benefit of packagers. The preprocessor allows
> some very neat tricks that were impossible before, for example
> generate changelog and release automatically from git metadata or pack
> the entire dist-git repository into an rpm-source tarball (effectively
> allowing unpacked repos to live in DistGit).
It would be nice to see this in some concrete example. E.g. in some
'private-rpkg-preview' branch in some of the existing Fedora packages, so
we can make a clearer idea about what this causes with real spec file
readability (diff) and the initial newcomer barrier. So we could e.g.
checkout that branch, and try to build the package. And see the real pros/cons.
Is this example good?:
https://pagure.io/hello_rpkg/blob/master/f/hello_rpkg.spec.rpkg
It can be built in Copr by SCM rpkg method.
There is also:
https://pagure.io/hello_rpkg_release/blob/master/f/hello_rpkg.spec.rpkg
with a dynamic release, the macro used is actually v3 macro, not yet
supported by Copr.
v3 macros are being introduced by this change. One can try to build
that spec either by rpkg-util (from Copr repo referenced in the
change) or by mock with rpkg_preprocessor enabled
I think pros/cons can be also revealed by discussion which is perhaps
better because it is shared...
> == Benefit to Fedora ==
>
> This change offers solution to some long-standing issues in Fedora
> around packaging (i.e. automatic release and changelog generation)
I personally wouldn't overestimate these issues, at least according to the
questionnaire I tried to do some time ago [1, 2] not many maintainers were
interested in the problem to even vote (and I was not surprised).
Well but there were also quite many mailing lists threads indicating
that people are interested in the topic. I cannot say if people are
interested or not...
These problems have trivial work-arounds/solutions, discussed in [1].
Idk If I want to get into the whole theory behind this problem. If
there is a trivial solution to the problem (i.e. automatic release and
changelog in this case), then perhaps it should be stated here and it
can be taken into account when deciding about this change. I would
like to note that this change tries to solve the problem but also in a
way that allows for more applications in future (e.g. unpacked repos),
which might be considered a potential advantage.
> while also offering some interesting future options (for example
> unpacked dist-git repos).
I think that it would be good to consider tito as alternative, when we
speak about binding spec with git-archive feature. Do you think it would be
possible to allow tito in future?
Maybe...If people want to use tito and ProvenPackagers and relengs are
okay with that...it's not really something I can decide.
There's also some Packit-team feature named source-git, is this
related?
It is related with regards to the "unpacked repos" that I described earlier.
-
Honestly, in general, I don't like tito, and I don't like rpkg much more.
Both are probably better for upstream development and release processes
(tito is more standard and convenient IMO) than some custom scripting.
But people need to know deeply the use-cases (and even implementation) to
compare.
Also note that we used to have problems [IIRC 3, 4] in Copr builds from
Fedora DistGit -- as the '{{{' syntax collided with some of the existing
packages.
Yes, there were two of them (last time I checked):
python-dns-lexicon.spec - uses {{{ }}} in comments
python-suds.spec - uses {{{ }}} in changelog at one place
But the feature is opt-in so a maintainer can tweak his/her spec file if needed.
I view this proposal as a risk that the spec files will look a bit more
weird, and the spec files maintenance will start diverging too much.
Everything happening for an overestimated triviality as IMO
the release/changelog is [1].
Well, even if this change is accepted, it doesn't mean people will use
the feature so if the feature is overkill or it is generally bad, it
will just die on its own.
>
> [1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> [2]
https://docs.google.com/forms/d/183dSFIN-i9rauEZ0_gtDia7dzkeX-hzfX0ncpqFM...
> [3]
https://pagure.io/copr/copr/issue/798
> [4]
https://pagure.io/copr/copr/issue/1219
>
> Pavel
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org