Re: Why does mingw-filesystem depend on mingw-binutils-generic?
On Wed, Aug 30, 2023 at 10:39:44AM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 30, 2023 at 10:36:26AM +0200, Sandro Mani wrote:
> > Hi
> >
> > I'd say, as least as it stands now, this is because the dependency
> > generators require mingw-objdump, see mingw.req [1].
> >
> > Sandro
> >
> > [1]
> > https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/mingw.req
>
> I see, good point.
>
> There's a concern in this bug:
>
> > >https://src.fedoraproject.org/rpms/virt-v2v/pull-request/2
>
> that pulling in mingw-srvany pulls in too many dependencies. We only
> need this binary because it gets copied into Windows virtual machines
> during various virt-v2v and virt-customize operations (it is used to
> run some "firstboot"-type services in Windows).
>
> The dependency chain is:
>
> virt-v2v -> mingw32-srvany -> mingw32-crt
>|
> \v
>-> mingw32-filesystem -> mingw-binutils-generic
>
> Both dependencies of mingw32-srvany are justified -- the program is a
> Windows binary that gets installed in the mingw "filesystem", and it
> needs various C runtime dependencies if you want to run it under Wine.
> But indirectly pulling in programs like mingw-objdump and mingw-strip
> seems less justified.
Thinking about the intended usage of mingw ecosystem in Fedora context,
the mingw RPMs are really considered to be devel input to enable end
user applications to be built. Such applications would typically be
bundled up into a NSIS/WXI installer binary, which end users will then
run in order to install the app on their Windows host/VM.
IOW, the mingw RPMs aren't particularly targetted at end users, more
developers.
When creating the application installer, the fact that mingw-filesystme
contains a dep on objdump/etc is essentially harmless. Your NSIS/WXI
recipe specifies exactly what files are to be included into the installer
binary, and ought to omit objdump/etc
> What do you think about adding {ucrt64,mingw32,mingw64}-srpm-macros to
> contain the rpmbuild macros and the dependency on mingw-binutils-generic?
That would be in keeping with the general Fedora approach for SRPM macros
these days, so despite what I said above, it might none the less be a
good idea. Still it will require updating every single mingw package to
add the new dep :-(
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Why does mingw-filesystem depend on mingw-binutils-generic?
On Wed, Aug 30, 2023 at 10:36:26AM +0200, Sandro Mani wrote:
> Hi
>
> I'd say, as least as it stands now, this is because the dependency
> generators require mingw-objdump, see mingw.req [1].
>
> Sandro
>
> [1]
> https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/mingw.req
I see, good point.
There's a concern in this bug:
> >https://src.fedoraproject.org/rpms/virt-v2v/pull-request/2
that pulling in mingw-srvany pulls in too many dependencies. We only
need this binary because it gets copied into Windows virtual machines
during various virt-v2v and virt-customize operations (it is used to
run some "firstboot"-type services in Windows).
The dependency chain is:
virt-v2v -> mingw32-srvany -> mingw32-crt
|
\v
-> mingw32-filesystem -> mingw-binutils-generic
Both dependencies of mingw32-srvany are justified -- the program is a
Windows binary that gets installed in the mingw "filesystem", and it
needs various C runtime dependencies if you want to run it under Wine.
But indirectly pulling in programs like mingw-objdump and mingw-strip
seems less justified.
What do you think about adding {ucrt64,mingw32,mingw64}-srpm-macros to
contain the rpmbuild macros and the dependency on mingw-binutils-generic?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Why does mingw-filesystem depend on mingw-binutils-generic?
Hi I'd say, as least as it stands now, this is because the dependency generators require mingw-objdump, see mingw.req [1]. Sandro [1] https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/mingw.req On 30.08.23 10:30, Richard W.M. Jones wrote: https://src.fedoraproject.org/rpms/virt-v2v/pull-request/2 mingw-binutils-generic contains a random selection of binaries: $ rpm -ql mingw-binutils-generic /usr/bin/mingw-nm /usr/bin/mingw-objcopy /usr/bin/mingw-objdump /usr/bin/mingw-strip For unclear reasons, mingw32-filesystem depends on mingw-binutils-generic since this commit: https://src.fedoraproject.org/rpms/mingw-filesystem/c/de21385695148a980c81d68396ffc883988fce74 but it's not explained why. It seems off that the base "-filesystem" package should need these binaries (why these are not others? why at all?) It seems like mingw-binutils-generic was added back in 2012 when we added 64 bit support, and contains "Utilities which are needed for both the Win32 and Win64 toolchains". Which is fair enough but it's unclear why they need to be in the filesystem dependencies. Rich. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Why does mingw-filesystem depend on mingw-binutils-generic?
https://src.fedoraproject.org/rpms/virt-v2v/pull-request/2 mingw-binutils-generic contains a random selection of binaries: $ rpm -ql mingw-binutils-generic /usr/bin/mingw-nm /usr/bin/mingw-objcopy /usr/bin/mingw-objdump /usr/bin/mingw-strip For unclear reasons, mingw32-filesystem depends on mingw-binutils-generic since this commit: https://src.fedoraproject.org/rpms/mingw-filesystem/c/de21385695148a980c81d68396ffc883988fce74 but it's not explained why. It seems off that the base "-filesystem" package should need these binaries (why these are not others? why at all?) It seems like mingw-binutils-generic was added back in 2012 when we added 64 bit support, and contains "Utilities which are needed for both the Win32 and Win64 toolchains". Which is fair enough but it's unclear why they need to be in the filesystem dependencies. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
