Results of BIND RFC

[Peter Jeremy]

Firstly, congratualtions to doubg at .

On 2010-Apr-02 05:15:26 -0700, Jeremy Chadwick <freebsd at jdc.parodius.com> wrote:
>1) In most scenarios (historically speaking), what gets updated quicker:
>base or ports?  Answer: ports.

In some ways this is a problem.  On the downside, it means that a
-RELEASE will never have bleeding edge features.  On the upside, it
means that a -RELEASE will never have bleeding edge bugs.

>2) What has proper infrastructure for dependencies and tracking of
>installed files as part of a software package?  Answer: ports.

I agree that this is a deficiency in the base system.  I have often
wished that there was some way of tracking exactly what part of
installworld had installed what file - but I accept that this is
a "difficult" problem.  It might be useful if there was a target as
part of install{world,kernel} that built a mtree database of what
was installed.

>3) How often do you see people posting problems with key pieces of
>FreeBSD infrastructure (device support/reliability or storage-related
>subsystems), followed by a response from a developer stating "this has
>been fixed in -STABLE" or "can you try the code from HEAD?"  Answer:
>often.

That's true of any non-trivial piece of software that has distinct
"developer" and "end-user" branches.  Moving to ports won't really
resolve the problem - the answer will still be "you need to update
to a newer version of that code".

Whilst I'd occasionally like to see less "bloat" (ie anything that I
don't use) in base, there is one significant benefit that I don't
recall seeing discussed in this thread - integration testing.  The
base system it built and tested as a whole.  This isn't practical for
the ports system.  Without the integration testing, you wind up in the
situation where port A and port B work in isolation but don't work
together - the port A maintainer says that the problem is port B and
the port B maintainer says that port A is relying on an optional part
of port B that they don't have the time/interest/expertise to
maintain.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20100402/3145dcaa/attachment.pgp