Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

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

 



On 1/20/20 7:03 PM, David Cantrell wrote:
On Wed, Jan 15, 2020 at 04:28:56PM +0200, Panu Matilainen wrote:
On 1/15/20 3:33 PM, Vít Ondruch wrote:

Dne 15. 01. 20 v 13:33 Panu Matilainen napsal(a):
On 1/15/20 2:13 PM, Miroslav Suchý wrote:
Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):
%changelog

%include changelog

+1


As I pointed out in
https://pagure.io/packaging-committee/pull-request/942, %include is
nasty because it breaks the stand-alone attribute of specs. There are
umphteen dupes and variants of bugs about systemd.spec's use of
%include breaking this and that use pattern that aren't systemd's
fault, it's just that %include isn't as useful as it initially seems.


Would it be helpful to open RPM upstream ticket to discuss when the
missing included file is problematic and whether there should be other
graceful variant of include? May be the %include should always behave
gracefully, because (S)RPM build is going to always fail due to missing
files specified by Source directive.

This was actually discussed upstream not too long ago, just can't find the reference offhand.

Basically an %include can never be allowed to fail as it can contain anything at all, including mandatory parts of the spec. In theory you can have a spec consisting of nothing but one or more %include directives.

(S)RPM builds are not an issue, it's spec queries, in particular for build-dependencies but also for other data. Rpm has special logic to allow missing sources and patches for query purposes, because they're only needed for building. Something changelog-specific could also safely ignore the missing file as %changelog is always an optional part of the spec.

I ran in to some issues when using %include for the changelog and it may be
related to this.  I made my changelog the Source1 file for the package and
did:

     %changelog
     %include %{SOURCE1}

It works for the packages I'm using it in.


This will essentially break "dnf builddep" for that spec, because the %{_sourcedir} for root is different from the user. It'd be less of an issue if it always defaulted to current directory, but that's a can of worms of its own.

It'll also cause general breakage and pain for those who expect the spec to be standalone parseable. For example the "all of rawhide" spec snapshot tarball becomes rather useless if specs use %include.

	- Panu -
_______________________________________________
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