(Resending without changes my reply which I've sent initially by mistake only to Kamil. He suggest that it is worth to resend it :) )
On 20 March 2017 at 22:23, Kamil Dudka <kdudka@xxxxxxxxxx> wrote:
> Even without above raw build logs preserved on koji enriched but full
> warnings verbosity has some very big potential.
I am not sure what you mean by "full warnings verbosity" but csmock allows you
to transparently add custom compiler flags without the need to change anything
in the build root or the packages being scanned.
Mistake. Not verbosity but more like visibility.
On building distro packages on official builder should be possible to see every possible detail. No hiding commands and params, enable print all possible warnings.
Theoretically it should be no problems with that as long as in CFLAGS/CXXFLAGS/FFLAGS is -Wall. However some developers in original projects build infrastructures hardcoded calm down visibility of such details.
I see now that in recent years number of such (nasty) projects decreased but still many are around.
From this point of view all hardcoded in spec files V=1 or other should be chased.
I'm not sure is it possible to add on git server side filters like it is possible to add in CVS/SVN servers t implement refuse commits containing some strings. in recent years I've spend working more as Sys Admin so my developers skills a bit weakened so I'm not fully familiar what is possible to do with git but I'm almost sure that such filtering on git server side must be possible as many people using previously CVS/SVN would feel using now git like with cutted hands.
So for example if in committed spec will be found for example "-Wno" or "V=<number>" such commit IMO should be automatically refused with message what is wrong in new version of spec file. Really such automation may cut many pointless discussions.
I think that many paragraphs from current Fedora Packaging Policies could be replaced by such filtering.
Simple it is consequence of approach "implement one time and use everywhere automatically".
All this kind of the things are disturbing possibility of precise control visibility of some things on build time on different stages life cycle of packages.
Other cases: hardcoding in make params -j params something different than "1".
Probably it would be possible to identify more such things.
I'm using many Linux spec files to compile stuff on Solaris so I personally would be happy to see replace all "make" by at least %{__make} if not %{make_build} and %{make_install}. On Solaris "make" it is not GNU make and GNU make is available as "gmake".
The same is with sed, awk and few other so some common set of macros must be introduced to make such reusability possible .. but it is really possible!!!
From this point of view things like "make %{?_smp_mflags}" is the same bad as using "make".
As between RedHat and Oracle still is kind level of tension/competition but this picture is more gray as long as both companies are almost sentenced to cooperate.
I would be very interested if such Solaris specific adaptations would be possible to push to Fedora? :P
(Guessing that it will be not warm welcome but always is worth to ask :) )
If someone is interested such adaptations will try to share some of my specs from my private stash.
BTW .. funny thing that on Solaris are not needed ANY {pre,post}{,un} scripts (Yes .. it is possible to have such state not only theoretically but practically as well!!), and I just found how to get rid probably +95% of all such scripts making typical rpm spec file simpler and less prone on mistakes without loosing even single grain from original functionalities .. pure "Ockham razor" ;)
Such change (definitely not about remove all scriptlets but probably close to 95%) needs to be done with Fedora current specs carefully as many are still quite messy. Probably it will be necessary to do such change in few stages but it is doable investing only few man/hour resources.
Such feature will move RPM much closer to some perfected on Solaris IPS (Image Packaging System) features.
IPS IMO is now the-most-advanced-packaging-software-available-on-this-planet ;-) despite its internal simplicity (IPS is probably 10 if not more times simpler than RPM)
Maybe it is not so easy to understand why such claim from some specific angle may be correct but ..
RPM still is my "first love" however I've learn in recent years many things which are still completely unreachable for typical Linux joe user/admin/developer so my point of view is a bit different.
kloczek
PS. <Censored> .. again wrote longer comment mostly off-topic :-> (who knows me knows that I'm mumbler)
Will try to write somewhere more about above maybe at the end of this week or next week, and only drop here link to such text.
I don't want to be to noisy here (I feel that I've already reached some boundaries ..)
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
