[Fedora-packaging] Re: supporting closed source operating systems?

[Jeff Spaleta]

On Mon, Jul 14, 2008 at 7:50 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> With your use of phrases such as "mingw cross-compiled crap", I

I have to apologize.. i use the word "crap" quite liberally as a
synonym for "stuff".  I need to stop doing that.  Just wanted to say
that first.



>On the contrary, this is exactly how Fedora packaging works right now.
>
>https://fedoraproject.org/wiki/Package_Review_Process
> "A Contributor is defined as someone who wants to submit (and
> maintain) a package in Fedora."
>
>https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages
> "When Fedora maintainers do not want or are not able to maintain a
> package any longer, they can orphan or retire the package."
>

All of these definitions speak to my original concern. If we let you
package up mingw built libraries.. there is nothing in our policy
which would keep any one else from doing exactly the same with other
libraries.  The "highly unlikely" argument doesn't hold water. There
is no bright line between you or any other contributor. If you can add
a subpackage.. then anyone else can..and we could quite easily in 2
releases end up with a large collection of cross-compiled paylods in
the main repository..that we expect all our mirrors to digest. I'd
rather plan for that sort of future, instead of pretending that you
and a few other contributors are special compared to other library
maintainers.  If you can't stand up a reason any better than "most
package maintainers won't be able to do it" then I have to assume that
other library maintainers will do it, because you will enable them to
do it. The stuff that is being drafted right now for the mingw SIG is
going to lower the bar significantly for the next group of maintainers
who want to get a dll compiled.

> Well, with respect this is a problem with the Fedora process.  Coming
> myself from a Debian background, I was always very surprised by the
> fact that once a package is in Fedora, it's virtually a free-for-all
> as to how that package is maintained.  In Debian, things are quite
> different - large numbers of automated tests run continuously over
> existing packages, and any which don't conform to policy have an
> escalating scale of sanctions against them.
>
> We can have a separate discussion about fixing the Fedora process.

No we are going to have a discussion in the context of dealing with
cross-compiled content.
You have to present how you expect cross-compiled content to be
reviewed for submission or I'm going to push back really hard, harder
than I am right now, about seeing any cross-compiled content into the
main repository.  This stuff is so different than are regular
workflow, that it requires some care concerning how to fit in the
review into our existence submission and review model.  These are
exactly the sort of questions I expect the mingw SIG to have some
initial answers for. You can't just throw a few of these subpackages
over the wall and call the work of the SIG done. You must, you
absolutely must propose how these things are to be reviewed.

>Same could apply to, eg., Perl packages (no offence to perl
>maintainers :-).  It is much more useful if these packages are part of
>Fedora, rather than unnecessarily cordoned off in a separate
>infrastructure.

Are you saying that enabling an additional repository in your package
manager is in fact too burdensome for a developer who is looking to
cross-compile? C'mon.

I don't understand why its much more useful in the main repo. The repo
definition would exist in the default configs and it could either be
enabled or disable by default. Hell you could enable it by default in
the developer spin, but disable it by default in the Desktop spin.
Isn't the target market for this stuff developers? The point however
is that we do not demand that all the main mirrors host this material.
They would be given a choice to pick this up and if you are wrong and
this becomes popular and a lot of people want to rebuild libraries
against mingw..we will have the structure in place to support it
without burdening the main repository with 2x the library binaries.

Stop dogging the question by holding up other sorts of payloads as
strawmen. If you continue to do that, I'm going to stop asking the
question hoping for a defensable answer.

First..these mingw libraries do not directly benefit Fedora users.
Perl, python, native libraries are directly provided to be used as
part of the users of the Fedora Linux distribution. There is a clear
distinction between what we provide currently and anything that is
cross-compiled.

Yes the mingw compiled dlls are useful to a subset of developers. I'm
not questioning that. But I am less and less sure that the value there
is worth opening up the main repository to this sort of cross-compiled
content.  And I am becoming more sure that the value that is there is
maximized by having an expansive set of such dlls.. not limited to the
immediate needs of libvirt.  By setting this up as a separate repo but
still inside the Fedora project, we can move forward and give you want
you need but also start a process by which we can maximize the
community value of these builds. In a lot of ways, this would almost
be its own distribution that was built on Fedora.

Second..we don't even ship all possible arches of the libraries that
we do have. We have this concept called secondary arches so that
individual contributors who want to extend Fedora onto new hardware
platforms can do so, by bring resources to the table to do it, without
asking the main mirrors to take on the distribution of that additional
compiled material.  A collection mingw compiled dlls feels very much
like a cross between a distribution and secondary arch. Which sort of
makes sense..since we are talking about cross-comppiling.

Why shouldn't we ask you or anyone else who wants to cross-compile for
another platform to be treated similarly from a policy perspective to
how we ask our secondary arch developers to be treated? Why can't we
make mingw a virtualized arch, and ask that the mingw payloads be
ifarch'd in the spec file and built only for a specific arch target so
that it can be treated as a secondary arch for a hosting and
distribution point of view?

Would you call secondary arches like sparc or arm "cordoned off" in
our current policy.


You aren't going to dodge the review burden on mingw payloads by
waving your hands and saying the Fedora process is broken. If you feel
our process needs fixing, then we fix it first before the mingw
payloads are allowed in... not the other way around.

-jef