This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] setup: port to 64-bit, part 2


On Mar 17 12:43, Christopher Faylor wrote:
> On Sun, Mar 17, 2013 at 10:35:46AM +0100, Corinna Vinschen wrote:
> >On Mar 17 02:27, Christopher Faylor wrote:
> >> If we're going to do that then I'd like the actual maintainers to start
> >> generating packages rather than random other people.  Otherwise chaos
> >> will ensue.
> >
> >I didn't know Yaakov is a random person.
> 
> I'll attempt to not follow your lead and respond to this
> matter-of-factly rather than hyperbolically:
> 
> In cygwin-apps, we have Marco and Yaakov discussiong cmake packages.
> Neither of them is the cmake maintainer.  The cmake maintainer isn't
> even weighing in, AFAICT.
> 
> In cygwin-developers, we have people discussing dash and perl who are
> not the maintainers.  There are versions of these programs available
> but I don't think the maintainers have had feedback into the packages.
> There is also a 64-bit version of binutils, using a different versioning
> scheme (a new trend), uploaded by someone who is not the binutils
> maintainer.

This is a test release.  It's not for the greater public.  It's still
much too early for that.  But we obviously need binutils to be able to
build packages natively.  These packages are there for testing, not to
replace the packages of the original maintainer.  Feel free to provide
your own packages.

> If we're thinking about making something that looks like a release then
> I'd like to do the considerate thing and make sure that the people whose
> packages you are releasing are ok with what's being done.  I, for
> example, am not ok with making a version of binutils available which
> uses a different versioning scheme.  I don't want to have to worry about
> that in a future setup.hint file.
> 
> Downloading and extracting tarballs is, IMO, different than making
> setup.hint'ed packages available and establishing a new release.  If we
> make a release I think it should be a beta version of an actual 64-bit
> release rather than something that has to be wiped out and restarted
> when 64-bit goes live.

What exactly speaks against making the life easier of those building and
testing packages in this early stage?
To run and test the 64bit stuff we need native tools.  Most of those
native tools exist now in a cygport-built version in the 64bit/release
area.  We would just like to test and be able to install the packages in
a convenient way, nothing else.

So, *please*, enable an upset for us working on 64 bit Cygwin, or
tell me how to do it myself.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]