Closed #393 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/393#event-10966512266
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I see %changelog -f as something that would create more issues than it solves,
but like said above, we too would very much like to see better integration with
external changelogs. Let's continue the external changelog discussion in a
dedicated topic:
The real issue is that %changelog carried in *.rpm is mostly useless bloat
these days, not how to integrate with other VCS systems, or ChangeLog files.
Setup a reliable persistent display of package spec changes, and %changelog
will wither away like the human appendix ;-)
--
You are receiving
The reluctancy is to add features that end up entirely unused. Oh, and features
which don't really fit rpm design principles to begin with.
Personally, I'd *love* to see Fedora get rid of the changelogs maintained in
specs and happy to help with it from my behalf, but until somebody actually
Of course some distributions found their way despite RPM upstream being
reluctant to support this or similar feature. The #69 just proves that. I did
not mentioned Fedora anywhere and I don't think that #69 was proposed by Fedora
people.
--
You are receiving this because you are subscribed to
https://github.com/rpm-software-management/rpm/pull/69 is related and has some
relevant discussion of the caveats etc.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah there are any number of ways to do it. Multiple distros are doing it via
other tooling sitting on top of rpm, that's an entirely valid route and already
proven route. Other options include having rpm execute some hook to pull data
from an outside source into the spec (and yes putting that
Well, one big advantage from the %include/%changelog way would be the possible
opt-in. If you want to automate "slapping the changelog itself at the tail of
the spec", then it means you have to actually change the build infrastructure
to do it.
TBH the biggest issue I see currently is that the
Splitting spec into multiple pieces (whether %include or otherwise) tends to
have all sorts of downsides, especially because it breaks long-standing
expectations of specs being standalone entities. I'm not actually opposed to
adding %changelog -f but I'm also not convinved it's be best way to
Actually, if ```%include``` automatically included the referenced file into
SRPM, that would be helpful as well. I realize, that the path could be
arbitrary, but if there was restriction, that could work ...
--
You are receiving this because you are subscribed to this thread.
Reply to this
10 matches
Mail list logo
