Date: Mon, 17 Oct 2011 23:52:54 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Stanislav Sedov <stas@FreeBSD.org> Cc: ports@FreeBSD.org, Ports Management Team <portmgr@FreeBSD.org> Subject: Re: [UPDATE] Re: Update on ports on 10.0 Message-ID: <F3D11CE6-0A01-4CA3-A42C-3690E1044F43@lists.zabbadoz.net> In-Reply-To: <20111017135130.d9caa4f1.stas@FreeBSD.org> References: <20111011063602.GO68552@droso.net> <20111017153551.23281532@tetcu.info> <20111017135130.d9caa4f1.stas@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17. Oct 2011, at 20:51 , Stanislav Sedov wrote: Hi, I shrinked that Cc: list dramatically. > On Mon, 17 Oct 2011 15:35:51 +0300 > Ion-Mihai Tetcu <itetcu@FreeBSD.org> mentioned: >=20 >>=20 >>=20 >> Here's a little status update: >> We iterated through a few -exp runs (basically for ports/161404 -- >> committed and ports/161431 -- skv@ any problem with it?). With those = two >> we can build around 7k packages. The majority of the rest can't be = built >> because of a few high profile ports that don't package: expat (6581), >> curl (975), jpeg(5057), lcms(1080), libiconv(11180), libltdl(1187), >> libogg(1947), pcre(5737), python27(5935). >>=20 >> http://pointyhat.freebsd.org/errorlogs/i386-10-latest/ >>=20 >> What we'd like to do next is see how many ports we can package after >> individually fixing those above. This will require a few other -exps >> since undoubtedly we'll find other highly-depended-on ports broken = that >> weren't tried because of the blockers above. >>=20 >=20 > It doesn't require an exp-run to understand that you won't move much = further > with just fixinng these ports. Well, there was a significant update from ~2800 to ~7000 ports by just = fixing 2 or 3? I think understanding these and handling them in a well defined = manner is a good idea. > patching similar to the patch Ed, Doug and other people proposed. = Actually, > that sed one-liner fixed like 99% of the ports in tree, excluding some = complex > 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). I think that's what he was saying as a possible next step. If they have = the cycles currently while waiting for RC1 to happen let them do it; we are = talking in having things within a month not in spring next year already. I would assume that the aforementioned patch might go into the = framework, would only be applied if a) OSVERSION>=3D10... and b) the port has a = knob that says "I need this to run". > WRT your "submit upstream" comment, personanlly, I'd argue against = this: We damn need it; they need to regen the stuff; it's going to take months if not years to get 80% to that point and a couple of projects might be dead and we might want to use a local patch then but the = sed-KNOB is a bandaid that must die again. I would argue that no port must add the KNOB (once it would exist, = should it) without having notified upstream. And you might know a lot better than I do but ideally there would be a new official libtool release before = that and ideally the libtool people would have by now fixed all the !FreeBSD = similar cases... /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F3D11CE6-0A01-4CA3-A42C-3690E1044F43>