Re: Mass spec file change: Adding BuildRequires: make

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

 



On 12/3/20 7:27 PM, Tom Stellard wrote:
On 12/3/20 8:32 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 5:17 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote:

On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote:

On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine.
___

If the packages use make and they BuildRequire: make then there is
nothing else to do.  I will try to re-run the scripts everyday to keep
the list updated.

I still think a lot of those are "false positives".
CMake has a hard Requires on make, so if I BuildRequires cmake, adding
"BuildRequires: make" is just redundant.
https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185


The only safe way to do this is to add BuildRequires: make to every
package that uses make.  We can't depend on these dependency chains to
keep things working, because they may not always be there.

That argument doesn't hold much water. CMake always requires a
backend, and right now it hard-requires make.
Until that's no longer the case, adding BR: make to packages already
having BR: cmake is just a waste of time.
If I can't be sure of *anything*, then wouldn't I have to add the
entire expected dependency tree as BRs?, down to glibc and filesystem?

There is a difference between packages that are needed to build and packages that are just dependencies of other packages.  For example, if your package uses make you should BuildRequire: make.  You do not need to BuildRequire: guile22 which is a dependency of make.  Why? Because if make drops the dependency on guile22, your package will continue to build correctly.  I am not suggesting that packages that use make need to also BuildRequire: guile22, for example.

+1


I do think cmake is a special case due to the new %cmake_build macros. It's possible for packages to only use the macros and rely on whatever make's default build system generator is.  In this specific case, I think that omitting BuildRequires: make is a valid option.

Indeed. If you're only ever invoking 'cmake' and not 'make', then you're simply using services provided by 'cmake' and how they go about providing it is none of your business, and its up to cmake to handle the dependencies in that case.


However, in the discussion on the mailing list for this change, not everyone agreed that cmake should Require make and this point was never resolved.  So, since there is still ambiguity here, I am planning to do the safest option, which is to add BuildRequires: make even for packages that use %cmake_build and do not invoke make directly.

I am not planning to start doing any changes for another 10 days.  Would it make sense to take this specific issue with the %cmake_build macros to FESCO and get a definitive decision?  I don't really have any strong opinions here, I just really want to avoid this change causing mass build failures either now or in the future, which is why I have been arguing for the 'safer' approach.  I am perfectly fine to take a different approach if FESCO decides something else would be better.

These discussions reappear on semi-predictable cycles and then go around and round and round...

Fundamentally, the generic issue at hand is not any different from the DSO linkage change ten years ago. For those who don't remember or weren't around, see
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
https://fedoraproject.org/wiki/UnderstandingDSOLinkChange

The world is that little bit better place thanks to that change, and all the principles and reasoning holds for package dependencies as well.

	- Panu -


-Tom

_______________________________________________
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

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