(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 <kdu...@redhat.com> 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 <http://lnkd.in/FXPWxH>*
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
