https://bugzilla.redhat.com/show_bug.cgi?id=1444925 --- Comment #5 from Neal Gompa <ngompa13@xxxxxxxxx> --- (In reply to Petr Šabata from comment #4) > (In reply to Neal Gompa from comment #3) > > For what it's worth, this is an awful idea, but since the Modularity guys > > clearly can't separate base runtime from build root, I guess we're faking > > multibuild packages now... > > > > If you're going to do this instead of doing it the right way, you might as > > well add "Supplements: (python3-devel and rpm-build and redhat-rpm-config)" > > so that people don't have to notice you did a bad thing and made this. > > I might be missing quite a lot here. Your comment was fairly vague. > > Faking multibuild packages? What do you mean by that? > multibuild is a concept that SUSE has with their OBS where you can have multiple spec files associated with a single set of sources, which build multiple source and binary packages[1]. Combined with source services, it's not completely terrible, though it can make it harder to build outside of OBS, depending on how it's done. This is a poor man's version of that, but it's too decoupled to be useful, since they must be manually updated independently, but in lockstep with each other. [1]: http://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.multibuild.html > What's wrong about separating language-specific dependency generators from a > generic package build tool? What's the right away in your book? Or are you > commenting on the transitive hard dependency on the generators, which is > different from how it was done with Perl, for example? > This particular dependency generator is part of RPM itself, and I as the upstream developer of it, prefer it to be maintained with RPM. Additionally, The *only* reason this is being separated is because the modularity guys want base runtime = buildroot, which is a completely wrong characterization to begin with. They freaked out because python3-setuptools is a requirement for the new dependency generator, because otherwise there's no way to reliably parse the Python metadata. I don't even agree with how we handled Perl, either. Perl dependency generators are still part of RPM, just like my Python one, and splitting them like this just promotes people monkey-patching and not upstreaming fixes. > While a reverse soft dependency wouldn't hurt anything, why would you want > it? Because then when normal humans want to build Python packages, they don't have to care that this split happened. We probably have to edit all the Fedora packages anyway, because weak deps are disabled in mock builds. Either that, or python3-devel gains a Requires on python3-rpm-generators, which would allow us to not have to mass edit the spec files. I'd probably go for the latter, personally, because then it's a "nothing changes" scenario everywhere. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
