Date: Sat, 3 Apr 2010 09:32:02 +1100 From: Peter Jeremy <peterjeremy@acm.org> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC Message-ID: <20100402223202.GD86236@server.vk2pj.dyndns.org> In-Reply-To: <20100402121526.GA64746@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> <4BB5CAA7.5030108@stillbilde.net> <20100402121526.GA64746@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--pZs/OQEoSSbxGlYw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Firstly, congratualtions to doubg@.
On 2010-Apr-02 05:15:26 -0700, Jeremy Chadwick <freebsd@jdc.parodius.com> w=
rote:
>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.
--=20
Peter Jeremy
--pZs/OQEoSSbxGlYw
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEARECAAYFAku2cGIACgkQ/opHv/APuIeMgQCggvdT7V76Zm2JuS/1z31DB6HK
WG0An35J/TIm1aiTSJCzOx3GpPC6yhxM
=gusw
-----END PGP SIGNATURE-----
--pZs/OQEoSSbxGlYw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100402223202.GD86236>