X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=lBFNW2M9is2+riAIAn7EeuWEqREx8lNxGFf+vM4cDBar1bRglcaO3
	ZazARBzIw0c2Ylz1yigryIeD36ODY+H2vft4hLIcyi5/M0z/AmgZDfx6b3D8HADn
	iloRjjfaGwSb1WmzRzj1owroft7jpOMQwukuygKqHURDHfHFkPfkuE=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=idAIZuc9CFiekFE/g4nYRazfDVo=; b=edroLmInlZbsqu4ul+jJXI4fNLWC
	Jxdm5NU4Pw+0jOl2WAnOFG4bL6zrLMk1Oi3D/Ll6wiVHZQaIKnuTPLEsYSaZyvOb
	q6fLaxTdFKhb93BY3f3Ll8WFi19dyBOw6Un4WDTa17fLyiXXE2Lh65oQsVIaqgD8
	2I5TUuvK5cNOdyM=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,TW_YG autolearn=ham version=3.3.1
X-Mail-Handler:	Dyn Standard SMTP by Dyn
X-Report-Abuse-To:	abuse AT dyndns DOT com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User:	U2FsdGVkX18Or7pk6gcwqGV/oH6hthbH
Date:	Fri, 21 Jun 2013 16:35:16 -0400
From:	Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
Message-ID:	<20130621203516.GA6468@ednor.casa.cgf.cx>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<51C0D956 DOT 4090905 AT etr-usa DOT com> <51C1B299 DOT 1000701 AT cwilson DOT fastmail DOT fm> <51C1F0F9 DOT 70601 AT etr-usa DOT com> <51C1FA8E DOT 3000307 AT users DOT sourceforge DOT net> <51C33F38 DOT 4080103 AT etr-usa DOT com> <20130620181056 DOT GA16923 AT calimero DOT vinschen DOT de> <74f7s89jvij7188akllq0l4qpp0i2ju35q AT 4ax DOT com> <20130621074934 DOT GF1620 AT calimero DOT vinschen DOT de> <20130621143411 DOT GA5918 AT ednor DOT casa DOT cgf DOT cx> <o5b9s8d8j58fmfmjv9r22eqc8cq330dhqs AT 4ax DOT com>
MIME-Version:	1.0
In-Reply-To:	<o5b9s8d8j58fmfmjv9r22eqc8cq330dhqs@4ax.com>
User-Agent:	Mutt/1.5.20 (2009-06-14)

On Fri, Jun 21, 2013 at 04:03:46PM -0400, Andrew Schulman wrote:
>>On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
>>>On Jun 20 22:38, Andrew Schulman wrote:
>>>>>If every maintainer would use cygport, it would allow us to change the
>>>>>build method to one along the lines of most Linux distros.  In Linux
>>>>>distros, the maintainer provides only the spec file and the source
>>>>>archive.  The actual build for all supported platforms could be done on
>>>>>a machine which creates the distro from there.
>>>>
>>>>That would be cool.  Let's do it!
>>>
>>>Uhm, that was a projection into the ideal future.  No provisions have
>>>been made yet.  We need to set up a central repository like Yaakov's
>>>cygwinports git repo and a central build mechanism.  The first we can
>>>probably shamelessly copy from Yaakov and set up over the next few
>>>months, the second needs a bit of hacking.
>>
>>I'm not sure if this reminder is needed but, I'm not switching to
>>cygport and I believe there are also a couple of other people using
>>non-cygport packagers as well.
>
>I guess there will always be some maintainers who don't want to use
>cygport, but I don't think that should be a reason to keep all of the
>rest of us from moving from the current labor-intensive manual build
>process, to a more labor-efficient automated process.

You've introduced a false dilemma.  There is no reason to assume that
any build system will be so limited as to be able to only run one type
of build mechanism.  The one that I use could easily be dropped into
any automated build.

Also, while I'm happy to help set up some kind of central repository,
please don't anyone assume that sourceware will be used to build
packages.  That is not an appropriate use of the system.  So, someone
(Red Hat?) would have to offer up a system to build everything.

I've said repeatedly that I'd like to fix the current upload mechanism
that we use for Cygwin.  I've tried a couple of different mechanisms but
neither was really good enough.

>For packages that don't work well with cygport, maybe it would be
>worthwhile to still support the current manual upload method.  The
>number of those packages would apparently be small.  But if a
>maintainer just doesn't want to use cygport, then I think we should ask
>whether the project should spend its resources accomodating that
>preference.

I don't see any reason to adopt that harsh a stance but again: false
dilemma...

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -