[UPDATE] Re: Update on ports on 10.0

[Bjoern A. Zeeb]

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 at FreeBSD.org> mentioned:
> 
>> 
>> 
>> 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).
>> 
>> http://pointyhat.freebsd.org/errorlogs/i386-10-latest/
>> 
>> 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.
>> 
> 
> 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>=10... 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

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.