https://bugzilla.redhat.com/show_bug.cgi?id=1444925 --- Comment #6 from Petr Šabata <psabata@xxxxxxxxxx> --- (In reply to Neal Gompa from comment #5) > (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 Associating sources with packages is done via the sources files in dist-git; multiple packages and branches can use the same sources. I'm not familiar with SUSE so perhaps I'm misunderstanding; I'll read the link. Thanks. > > 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. Ah, a clash of opinions :) I believe such generators should be maintained separately, in both downstream and upstream. I supported the Perl change and I welcome this one as well. I happen to be one of "the modularity guys" and while I definitely dislike the Python generators currently being part of rpm-build and depending on the full Python installation and yes, it was what, at least partially, ignited a brief discussion about this change, it's not the only reason here. I dare to say the reason is that some people actually think it's a Good Thing going forward. Again, I do, for instance. > > 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. I see. Yes, there are two main ways to do this. One is to add the generators build dependency to every Python package (or more precisely, every Python package whose maintainer wishes to use this feature), which I think is more flexible and is what was done for Perl but would be a massive undertaking. Another is to add that dependency to python*-devel which is what the Python team plans to do, from what I heard. So it should be relatively painless. -- 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
