Bug 1771760 - bmake cannot be installed because of a missing dependency
Summary: bmake cannot be installed because of a missing dependency
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bmake
Version: 31
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-12 22:23 UTC by Gabor Gergely
Modified: 2020-06-10 12:25 UTC (History)
2 users (show)

Fixed In Version: bmake-20200524-1.fc32 bmake-20200524-1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-03 01:49:34 UTC
Type: Bug


Attachments (Terms of Use)

Description Gabor Gergely 2019-11-12 22:23:48 UTC
Description of problem:

cannot install bmake, as its dependency mk-files is not available.


Version-Release number of selected component (if applicable):  bmake-20180512-4.fc31.x86_64


How reproducible: always, consistently


Steps to Reproduce:
1. dnf install -y bmake

Actual results:

Error:
 Problem: conflicting requests
  - nothing provides mk-files needed by bmake-20180512-4.fc31.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Expected results:

bmake is installed along with its dependencies

Additional info:

Comment 1 Fedora Admin XMLRPC Client 2020-04-06 16:48:25 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 2 Fedora Update System 2020-05-25 18:58:05 UTC
FEDORA-2020-67eedc26ca has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-67eedc26ca

Comment 3 Fedora Update System 2020-05-25 19:00:24 UTC
FEDORA-2020-e25327f046 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e25327f046

Comment 4 Fedora Update System 2020-05-26 04:41:21 UTC
FEDORA-2020-e25327f046 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e25327f046`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e25327f046

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Update System 2020-05-26 04:57:04 UTC
FEDORA-2020-67eedc26ca has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-67eedc26ca`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-67eedc26ca

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2020-06-03 01:49:34 UTC
FEDORA-2020-e25327f046 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Fedora Update System 2020-06-03 02:09:43 UTC
FEDORA-2020-67eedc26ca has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 8 Gabor Gergely 2020-06-05 13:04:18 UTC
Hi!

Now the package can be installed, but it is not functional. The package did not require the 'mk-files' dependency anymore, and installed, but without those files the bmake tool cannot be used as intended.

I think the proper fix would have been fixing the build of 'mk-files' package, not removing them as dependencies. 

Ideally the following should work (provided gcc is installed, and is available as alias cc):

~~~sh
sudo dnf install bmake

cat << EOF > hello.c
#include <stdio.h>
int main(char **argv)
{
        printf("Hello world!\n");
        return 0;
}

EOF

bmake hello

./hello
~~~

bmake works this way on other distributions, and worked this way on earlier Fedora releases.

What happens now is:

~~~sh
bmake hello
~~~

~~~
bmake: no system rules (sys.mk).

bmake: stopped in /home/ggergely/bmake-test
~~~

and obviously `hello` cannot be executed this way.

Using a makefile with no reference to the system makefiles also does not work.

Thanks!

Comment 9 Petr Menšík 2020-06-09 14:03:29 UTC
(In reply to Gabor Gergely from comment #8)
> Hi!
> 
> Now the package can be installed, but it is not functional. The package did
> not require the 'mk-files' dependency anymore, and installed, but without
> those files the bmake tool cannot be used as intended.
> 
> I think the proper fix would have been fixing the build of 'mk-files'
> package, not removing them as dependencies. 
> 
> Ideally the following should work (provided gcc is installed, and is
> available as alias cc):
> 
> ~~~sh
> sudo dnf install bmake
> 
> cat << EOF > hello.c
> #include <stdio.h>
> int main(char **argv)
> {
>         printf("Hello world!\n");
>         return 0;
> }
> 
> EOF
> 
> bmake hello
> 
> ./hello
> ~~~
> 
> bmake works this way on other distributions, and worked this way on earlier
> Fedora releases.
> 
> What happens now is:
> 
> ~~~sh
> bmake hello
> ~~~
> 
> ~~~
> bmake: no system rules (sys.mk).
> 
> bmake: stopped in /home/ggergely/bmake-test
> ~~~
> 
> and obviously `hello` cannot be executed this way.
> 
> Using a makefile with no reference to the system makefiles also does not
> work.
> 
> Thanks!

Oh, did not know this was supposed to work. But it does, once mk-files are installed (again). I have started mk-files review under bug #1839870, because they seem to be still maintained. But their refresh would take more steps than preserving bmake.

Please, report this as a new bug. I think bmake can work with existing Makefile, so it should Recommends: mk-files instead.
They are not mandatory for some use cases, but are obviously missing in this case. The last successfully built mk-files could be used until more recent pass review [1].

I am surprised GNU make allows this use as well. I expected Makefile file have to exist, but it does not.

1. https://koji.fedoraproject.org/koji/buildinfo?buildID=1130737

Comment 10 Gabor Gergely 2020-06-09 16:40:55 UTC
I also tried it with the following makefile, which also didn't work without mk-files, thus I think it is a hard dependency in case of bmake.

Consider the following:

~~~
[ggergely@semissis ~]$ cd bmake-test/
[ggergely@semissis bmake-test]$ ls
hello.c  makefile
[ggergely@semissis bmake-test]$ cat makefile
hello: hello.c
        cc -o $@ $>
[ggergely@semissis bmake-test]$ cat hello.c
#include <stdio.h>
int main(char **argv)
{
        printf("Hello world!\n");
        return 0;
}

[ggergely@semissis bmake-test]$ bmake
bmake: no system rules (sys.mk).

bmake: stopped in /home/ggergely/bmake-test
[ggergely@semissis bmake-test]$
~~~

No implicit rule is invoked in this case, still the lack of system rules is a blocker.

I happily open a new bug if that is the way to go, just lets agree on what should be its scope/goal first.

Should I open a new bug with the content: "bmake should explicitly depend on mk-files?"

Comment 11 Petr Menšík 2020-06-10 12:12:06 UTC
Okay, you were correct. bmake indeed cannot work without mk-files well. I had installed mk-files from recent source and it worked well. After I removed it, most targets stopped working.

Fortunately, upstream maintainer pointed me to already shipped mk files inside bmake release. Extra package is not necessary, just noarch subpackage would be sufficient. So new build would have mk-files shipped.

But sure, once a bug is closed, please open a new one to report errors instead. I have noticed with luck this time, there are some comments. A new bug is more visible.

Comment 12 Gabor Gergely 2020-06-10 12:25:00 UTC
Ok, so should I open a new bug, to let you book your work onto, or this problem will be solved because I got lucky? It is no effort for me, just want to make sure duplicates and bookkeeping efforts don't waste valuable development time. Opening a new bug is a few minutes for me.


Note You need to log in before you can comment on or make changes to this bug.