Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]



It would be possible (in principle) to have the ports system be able to pull
source from a seperate FreeBSD src tree, instead of a distribution tarball
and patches (maybe even directly from src-contrib). I wonder if there are
other ports that are really pretty highly customized for FreeBSD that would
work better as vendor branch CVS imports (like sendmail is, I presume). Has
this been considered already? This could certainly help the ~50% packages in
src-contrib that are duplicated in the ports tree, which I feel is a
deplorable state of affairs.

I guess that it would be appropriate to list what I feel are the advantages
of moving these packages out of src-contrib:

1) It feels much more logical and consistent. This is roughly analagous in
strength to the "tradition" or "heritage" argument for keeping them in
src-contrib, so I figured I'd include it.

2) Security. The interests of system security dictates that you include as
little as possible in a default system, and allow additional software to be
added on *as needed*.

3) Management. I can pick a version, upgrade, downgrade, switch to a
different but similar software package, and stop using the software
altogether all without having to touch any other part of the system.

4) Insulation. People not using the software will not be affected by changes
to the software, as recently happened with sendmail.

5) Cohesion. Some software lives in both src-contrib and ports (in fact
about half of src-contrib, by my count). Having two sources for the same
software has all sorts of problems. Bugs/security holes need to be fixed in
two places. People get confused as to which software they are running, and
under what circumstances. In extreme cases, both software packages could
come into use in different contexts, and if they were divergent and
incompatible versions... well, you get the point. (Some people have
characterized this as adding "character" to the system, which boggles my
mind.)

The arguments that I've heard so far to keep them in src-contrib:

1) Tradition/heritage. It's part of BSD, and people expect it to be there.

2) They are in active FreeBSD-specific development (which isn't readily
accomodated by the ports system as it stands)

3) We'd lose the contribution of Greg if sendmail was moved out of the core
system. (Could this possibly be true?? I assume that Greg would eventually
become involved in the discourse if it looked like something would actually
happen, and his veto would definitely shut down the possibility of doing any
of this. Some people are just That Important.)

I'm sure I missed points on both sides. Comments?

It also occurs to me that pro-port items 1, 2 and 4 could be at least partly
accomplished with changes to the installer, as follows:

* BIND, sendmail, and anything else in src that might fall on the other side
of the razor are moved into a different distribution set for the installer,
similar to the non-port XFree86. They could be selected by default -- the
main idea is to allow a person to install FreeBSD from media without
packages that aren't _logically_ part of the core system (heritage and
tradition notwithstanding)

* It'd definitely be nice if a skeleton make.conf was set up based on which
distribution sets were selected during the install -- even if BIND and
sendmail are never changed at all. This would mean somebody who installed a
stripped down FreeBSD system wouldn't unexpectedly get all those packages
when they started tracking a branch.

Unfortunately, I don't know much about the installer or the generation of
distribution sets, so I have no idea if that would be difficult or not.

/Yeasah



To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-stable" in the body of the message