Distinct base and ports update ?
bconstant at be.tiauto.com
Thu Mar 24 00:21:36 PST 2005
> On March 22, 2005 11:50 pm, Constant, Benjamin wrote:
> > I think this may work if I use two cvsup files (one for the src-all
> > and the other one for the ports) using a different date inside.
> You should always use separate supfiles for the source and
> ports trees.
> Why? Because the ports tree changes on a daily basis, and
> the source tree may only change every couple of months
> (depending on the branch you are tracking). Why compare
> every single file in the source tree on your system and the
> cvsup server when all you want to do is get the latest ports tree??
I agree with you.
> Keep them separate. Keep the tags separate. And only update
> the source tree when you need to.
This is what I want to do but I must be sure that if I update my mirror, I
can use the same base across multiple updates.
That's why the date parameter sounds interesting to me.
> And, if all your systems are on a LAN, then why not NFS mount
> the /usr/src and /usr/ports directories off a central system?
> That way, you only have to update one system, and you're
> guaranteed that all the servers have the same source and
> ports trees. Just set the work directory prefix (it's listed
> in the ports(7) man page) so that the compilation work
> directories are local, and you're set.
Unfortunately I can't but the idea is good :-)
> Alternatively, just have 1 build system that makes packages,
> and copy those packages out to the other servers, and do the
> installs/upgrades with packages.
This is also a good way of working as it help you to remove (for example)
compiler stuff from your system.
Keeping your installation as minimal as possible is always a good choice.
Thank your for these tips.
The information contained in this transmission may contain privileged and
confidential information. It is intended only for the use of the
person(s) named above. If you are not the intended recipient, you are
hereby notified that any review, dissemination, distribution or
duplication of this communication is strictly prohibited. If you are not
the intended recipient, please contact the sender by reply email and
destroy all copies of the original message. This communication is from TI
More information about the freebsd-stable