Date: Wed, 19 Oct 2011 10:59:38 +0300 From: Ion-Mihai Tetcu <itetcu@FreeBSD.org> To: Peter Jeremy <peterjeremy@acm.org> Cc: Stanislav Sedov <stas@FreeBSD.org>, ports@FreeBSD.org Subject: Re: [UPDATE] Re: Update on ports on 10.0 Message-ID: <20111019105938.5aa842a4@FreeBSD.org> In-Reply-To: <20111018223146.GA93539@server.vk2pj.dyndns.org> References: <20111011063602.GO68552@droso.net> <20111017153551.23281532@tetcu.info> <20111017135130.d9caa4f1.stas@FreeBSD.org> <20111018223146.GA93539@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ slightly reordered ] On Wed, 19 Oct 2011 09:31:46 +1100 Peter Jeremy <peterjeremy@acm.org> wrote: > [trimming cc list] > > On 2011-Oct-17 13:51:30 -0700, Stanislav Sedov <stas@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. > > > 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. Unfortunately we don't seem to have any other way to go, for the big majority of the ports. The fix is basically identical, so it doesn't make sense to have a zillion of patch files in a zillion of ports. What, on the other hand, makes sense is to have the fix that should include: a) a KNOB (WITH_FBSD10_FIX or similar), b) that only is run from bsd.port.mk when OSVERSION>1000000 c) runs the latest version of the above patch. The KNOB's existence allow us to turn on the fix only for broken ports, and easily know what these broken ports are -- so we can poke maintainers from time to time about upstream fixes, ... There are exceptions, e.g. python and perl. > >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. Presumably $UPSTREAM wants it software to be able to build on FreeBSD even outside the PT, especially if this doesn't imply much work on his part. > >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. Yep. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111019105938.5aa842a4>