X-Recipient: archive-cygwin@delorie.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:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=LCk9gwyUAd2cfU4FYDjIYZGSvRJ8ymB6aDnfzid05l8tGsLt99MID
	KmbeBG/+h5r8iTQw5tqjCra9noLWEkcW9lt+d8xVFVclPqHpIoyIs5xjHAKKNpqi
	zy6vywLd8LzcQSEHZ0mrTN6sU1zgPZg9fRdAXlTt6J85ILO/hlB/Hk=
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:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	 bh=v5J18JUnwnGxxaVOhH5u4tJXZlM=; b=Gh/bMqtsvVt3VInfuRQEhIi8qZk6
	Vztzii5pvvcc8G5SxNL+TLYe0c8o4N/yAbVECFn+NV9e/BWVJVALAzD/QG370bdO
	ET5zc5NPT0axZ2DXN7P1Vp+D8+UToR0ZQyZPxMnyHzlrDZdYIId6+w0rhvBsscG5
	Yb7y8HcmEqPSPQI=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TW_YG autolearn=ham version=3.3.1
To: cygwin@cygwin.com
From: Andrew Schulman <schulman.andrew@epa.gov>
Subject: Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
Date: Fri, 21 Jun 2013 16:03:46 -0400
Lines: 41
Message-ID: <o5b9s8d8j58fmfmjv9r22eqc8cq330dhqs@4ax.com>
References: <51C0B08E.8080900@etr-usa.com> <CABEPuQJJpRfPKSwZ7M0eTOdp1HxDcmvuy1=qXFHBw-8kLkZ1ZQ@mail.gmail.com> <51C0D956.4090905@etr-usa.com> <51C1B299.1000701@cwilson.fastmail.fm> <51C1F0F9.70601@etr-usa.com> <51C1FA8E.3000307@users.sourceforge.net> <51C33F38.4080103@etr-usa.com> <20130620181056.GA16923@calimero.vinschen.de> <74f7s89jvij7188akllq0l4qpp0i2ju35q@4ax.com> <20130621074934.GF1620@calimero.vinschen.de> <20130621143411.GA5918@ednor.casa.cgf.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Archive: encrypt

> 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.  

This vision seems like the future to me.  More people will maintain more
packages if they can spend less of their time babysitting manual build and
upload processes.  The distro maintainers should ultimately see a decrease
in their labor too.

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 understand that the project doesn't seem ready to take on this task yet,
but when there's a need for development or system administration effort to
make that vision happen, I'd like to help.

Andrew


--
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

