https://bugzilla.redhat.com/show_bug.cgi?id=1805928 --- Comment #14 from Fabio Valentini <decathorpe@xxxxxxxxx> --- (In reply to Artem from comment #13) > Seems like we have some misunderstanding there, but that's obviously since > you asking meta questions. So what's exactly a problem here? You still > didn't said. What is a real fix for this specifically case since there > already 'planner' package exist in Fedora? And why you asking like i did > something criminal since *you* as person who responsible for Elementary > stack didn't wrote any guidelines for it? Why should there be specific Guidelines for elementary stuff? All their projects are now 99% standard, simple meson projects, where the general guidelines are definitely enough. There are also no Packaging Guidelines for GNOME, KDE, XFCE, etc. ... because it's not necessary. That said, there *are* Guidelines for package Naming, specifically: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_general_naming But well, the package is named "elementary-planner" now, even though it's not an official elementary project. At least on NixOS, they have the same problem and they also named it "elementary-planner" despite it not being an official elementary project, so at least some distros are somewhat consistent here. Also note that the original "planner" package is also no longer present on fedora 32+ (it was retired, probably because it didn't build anymore on F31+, or because somebody just orphaned it), so you could eventually rename this package and drop the "elementary-" prefix. > > Fair enough, but the packaging Guidelines still specify that you should document *why* you're modifying build flags. > > In case with LTO this is obvious why and as you already seen other > maintainers not specify too why they build with LTO. But sometimes i > document even how much profit we got there in percentage ratio, see [1]. So > i am not "arbitrarily" building with -flto, as you stated. Side note: I have not seen any package enabling LTO before I looked at this one. There may be "many", but this is the first one I'm interacting with. So I was just surprised that it's there without a comment. While you're right that it might be obvious what -flto does, but it might not be obvious to everybody! That's why a comment is always nice, if only to say "this flag enables link-time optimizations to make the application run faster" ... > > The Change about enabling LTO by default also has no bearing on this, because it would change the *default* build flags, and thereby *by definiton* moving the goalpost for everybody. > > One again, since you asking meta question i have no idea what has bearing on > this and what doesn't for you. And you quoting wrong thesis. Thesis was why > i enabling LTO in *some* my package. Answer was for the same reason that > mozjs did and for the same reason why it was proposed to enable it by > default in F32. And i asked many times other maintainers about LTO > specifically and there is nothing wrong with that. > > [1] https://src.fedoraproject.org/rpms/kakoune/blob/master/f/kakoune.spec#_3 > Why you not ask why arbitrarily mozjs [1] and firefox built with -flto and > why LTO by default proposed in F32 [2]? I suppose you wanted to say "duh, of course adding -flto makes things run faster, why is he even asking" here? I probably misunderstood this paragraph when I first read it ... I know what compiling with -flto does, I wasn't asking for myself, but for people who might *not know*. Maybe that answers your question? --- I'm sorry if my questions seemed like nonsense to you. That was not my intention. If you just said "I'm not modifying the build flags (so this is okay), I'm only adding LTO to make this run faster, maybe I'll add this as a comment to the .spec file with the next update" I would have been 100% satisfied. Again, I apologize if my questions were too "meta". -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
