On Sun, 20 Dec 2020 at 00:23, Pavel Raiskup <praiskup@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/thread/2G6OSOSM76O2V6K4COIE2QHNXIBSXPFR/ > [2] https://docs.google.com/forms/d/183dSFIN-i9rauEZ0_gtDia7dzkeX-hzfX0ncpqFMYxw/edit#responses > [3] https://pagure.io/copr/copr/issue/798 > [4] https://pagure.io/copr/copr/issue/1219 > > Pavel > > > _______________________________________________ > 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
