Re: CVS commit: pkgsrc/cross/mingw-binutils

[John Marino <netbsd%marino.st@localhost>]

On 10/9/2012 22:12, Aleksej Saushev wrote:
> John Marino<netbsd%marino.st@localhost>  writes:
>
> > On 10/9/2012 21:05, Aleksej Saushev wrote:
> > > I don't agree that we should favour somewhat experimental systems running
> > > GCC 4.7 rather than more stable ones running GCC 4.1-4.4.
> > > Personally, I'd rather see the package building with older compiler than
> > > newer one, downgrading compiler is usually easier path.
> >
> > You really need to watch what you say.  That is at least the
> > fourth time you have implicitly or explicitly insulted DragonFly
> > on these lists and that is uncalled for.  FYI, DragonFly has two
> > base compilers and the default compiler is gcc 4.4, still true
> > for version 3.2 to be released in two weeks.
>
> Whether you love it or not, DragonFly is even more on fringe than
> NetBSD, which is not the single platform we support.
> So, please, stop putting cart before horse.


Lack of popularity doesn't give you the right to disparage any of the 
platforms that have chosen pkgsrc as their package repository.  If not 
for the NetBSD-specific emulators, DragonFly would have at least the 
same number of packages building as the NetBSD counterparts do. 
Frankly, pkgsrc really should be split off of NetBSD into a separate 
project which might address some of this second-class citizen vibes I'm 
getting.


> It doesn't matter whether they are declared unmaintained by GCC developers,
> we are not talking about developing GCC. We're talking about building
> software packages. Systems we support do use GCC 4.1, sometimes GCC 3.4 even,
> and those systems are more important to us than not-yet-released Debian.

Unreleased for a matter of days.  But I believe you mean it.

> I'm not avoiding GCC 4.6 as you're trying to present. But I'm concerned
> that you consistently ignore those who use GCC 4.1.
> You could have solved it in backwards-compatible way, pkgsrc framework
> is powerful enough for that.

Alright, you give me the standard solution to this problem right now.
Patching the source is not really an option.  Maybe it's a single patch, 
but there could be dozens of violations in an older package.  I'm 
guessing -Werror removal would be the standard way.  Luckily there 
doesn't seem to be too many packages with -Werror set.