Re: Plan for tomorrows (20080910) FESCO meeting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard W.M. Jones wrote:
> On Wed, Sep 10, 2008 at 10:03:07AM -0400, Josh Boyer wrote:
>> Can you comment on what part of his draft you find objectionable?
> 
> Specifically three things:
> 
> (1) It imposes upon us the need to use a separate repository, which is
> based on the false assumption that we will be rebuilding a substantial
> proportion of all Fedora packages, like some sort of secondary
> architecture.
> 
Can you list some of the impacts a separate repository would impact
MingW if #3 was changed to enabled by default?

> In reality this is not the case - we only wish to rebuild a few common
> libraries.  Secondary architectures rebuild every package, including
> applications, which we have no intention of doing even if it were
> possible (which it isn't).
> 
This is not a strong point.  The people pushing MingW at the moment are
not necessarily the same people that will be pushing it four years from
now.  If the whole aim for all time of the MingW SIG were to be able to
develop the virt stack for Windows on Fedora, I'd be disappointed.
Wooing developers to use Linux even when they have to build for Windows
is a good thing in my eyes.

> (2) "All packages must first be natively available in Fedora before
> they can be in the MinGW repo"
> 
> This is a considerable restriction.  A useful Windows cross-
> development environment must include packages like NSIS installer, GNU
> gettext and PortableXDR, none of which would make sense as standalone
> Fedora packages.
> 

rpm -q getext
gettext-0.17-4.fc9.i386
:-)

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?

> (3) "The repository definition(s) will be included in fedora-release
> but will be disabled by default."
> 
> But no reason is given why this extra repository should be disabled by
> default.
> 
There are reasons but I don't know if they are valid.

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.

> Much of the draft states the obvious, like "All packages submitted for
> MinGW repo must pass a formal review" and "any MinGW specific caveats
> must be documented in the Fedora Packaging Guidelines".  And there's
> also the plain odd stuff like the requirement to use our own signing
> key.
> 
Maybe it's good to state the obvious then :-)  Separate repo == separate
key is pretty obvious to me.  Especially since we're presently going so
far as to make new keys for separate Fedora releases.

> Anyway, I don't want to spend too long on this since the actual people
> doing the work are trying to produce a proper, detailed technical
> packaging draft here:
> 
> https://fedoraproject.org/wiki/PackagingDrafts/MinGW
> 
> No "1000 ft views" in here.
> 
The thing is, the 1000 ft view is necessary too.  Your stuff is great
for the technical side which I'll get to work with in my role on the
Packaging Committee.  But Axel Thimm brought up the political and Fedora
Project Policy side which Jef has been doing a good job of countering on
FAB, the Board, and here.

-Toshio

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux