[trimming cc list] On 2011-Oct-17 13:51:30 -0700, Stanislav Sedov <s...@freebsd.org> wrote: >ones (like GCC). So why not commit that patch as a KNOB to bsd.port.mk like >it was initially proposed and let people use it in individual ports makefiles >to fix them (and portmgr@ can commit the initial bunch of these knobs)? This >is the easiest thing you can do now, and you will be able to abandon it when >the better solution is available (which is unlikely).
Once hackish work-arounds get committed, it is extremely difficult to root them out. The last time the project included a temporary hack to assist with a similar problem (the aout to ELF migration in FreeBSD 3), it took more than a decade to get the hack out of base and after 13 years, there are still 71 ports (by my count) with local work-arounds. >WRT your "submit upstream" comment, personanlly, I'd argue against this: Ports are never going to get fixed unless we advise the upstream maintainer that there is a problem. >this is not the upstream maintainer's problem, it the buggy tools they use Unfortunately, we are unlikely to convince many people that GNU autocr*p is broken by design. But it _is_ the upstream maintainer's problem that they chose to use buggy/broken tools. >to generate the configure scripts, so until the fixed version of libtool >is available in all major distributions and widely installed, they're not >going to replace it or patch locally. A reasonable approach would be to come up with fixes to libtool and the rest of autocr*p and get them applied to the "master" versions. Then go to the upstream maintainers with something along the lines of "your foobar-1.2.3 will not work on FreeBSD 10 due to bugs in libtool and/or autocr*p. This has been in version X of those tools. If you are unable te update, could you please apply the following patch locally". Of course, this only applies to the latest version, old versions are going to need to be patched in the ports tree. > Given the debian/ubuntu release >schedule, this is not going to happen earlier that 1-2 years from now, and Based on the objformat mess, whatever is done will hang around in the tree for at least a decade so we are far better off spending some time now to come up with the best solution, rather than quickly committing a work-around that we spend the next decade regretting. >Whatever action we take will >your patches/requests sent could potentially cause them to abandon FreeBSD >support altogether requiring a lot of work to maintain which will be totally >understandable. I don't see how this follows. It's no different to upstreaming any other FreeBSD-specific change. -- Peter Jeremy
pgplPPw6zkySi.pgp
Description: PGP signature
