2008/9/10 Toshio Kuratomi <a.badger@xxxxxxxxx>: > I think that some discussion of this is warranted, though. It would be > desirable to have a program that can run on Linux and generate Windows > installers, for instance, but do we want to force our developers to do > the work of adapting a Windows program like NSIS installer to run on > Linux natively? You could as a compromise include a clause to have FESCo rule on exceptions to this on a case by case basis. Though to do that, I think it would be best to narrowly defined what the purpose of the exceptions must serve... development aids... so that FESCo is only asked to make narrow exception judgements. If the exceptions criteria are more broadly defined as to allow end user applications you'll have a harder time down the road applying a consistent exceptions policy without getting wrapped up in debates over Fedora's purpose. I'd rather front load as much of the policy pain around these payloads with explicit policies now..then have reactionary policies on down the line. > When dep solving or downloading filelists.xml for resolving a filename > dep, you will end up including MingW stuff unnecessarily which slows > things down. But I don't know that that is sufficient reason to disable > the repo by default. As long as individual Spins are explicitly told to they are allowed to disable or enable and that we are not requiring them to keep it in the default state. I fully expect the Developer Spin to enable it. I fully expect the Desktop Spin to disable it. The default state only impacts the traditional installer scenario, and ultimately releng has the final decision as to whether they want this enabled or disabled the mingw repo by default. The suggested default has the least impact on releng. FESCo is certainly free to invert that suggestion so that the new repo is enabled by default. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
