Re: Move /usr/sup to /var/db/sup?
From: Garance A Drosihn (drosih_at_rpi.edu)
Date: 05/21/04
- Previous message: Peter Jeremy: "Re: Network Stack Locking"
- In reply to: Crist J. Clark: "Move /usr/sup to /var/db/sup?"
- Next in thread: John Polstra: "Re: Move /usr/sup to /var/db/sup?"
- Reply: John Polstra: "Re: Move /usr/sup to /var/db/sup?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 21 May 2004 17:38:56 -0400 To: "Crist J. Clark" <cjc@freebsd.org>, freebsd-arch@freebsd.org
At 12:36 PM -0700 5/21/04, Crist J. Clark wrote:
>Just a minor thing, but I would think[0] most people would
>agree that /var/db/sup is a much more logical place for the
>CVSup "base" directory than /usr/sup. Yes, it doesn't take
>up much space on /usr, but for those who don't want to write
>to /usr[1] too much or mount /usr read-only, it's an irritant.
>
>Of course, there is one big reason not to change it, because
>it would be a change.
I have all my own sup-files anyway, so I do not have any
strong opinion on this. But there is one minor advantage
that I have noticed in having the "base=" directory in the
same partition as the "prefix=" directory. If the partition
matching "prefix=" is not mounted, and if the "base=" file
is on that partition, then any attempt to run the cvsup will
immediately fail.
However, if the "prefix=" partition is not mounted, and the
"base=" directory *is* available (because it is on a different
partition), then the cvsup will go right ahead and download
everything into the wrong partition. Depending on how your
machine is set up, this can be rather disastrous... (it was
for me, at least!)
I have no idea if that is why someone went with /usr/sup in
the example supfiles, though. I do not object to making the
change to use /var/db/sup, but then I don't use those example
files so my vote wouldn't mean much anyway... :-)
-- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Peter Jeremy: "Re: Network Stack Locking"
- In reply to: Crist J. Clark: "Move /usr/sup to /var/db/sup?"
- Next in thread: John Polstra: "Re: Move /usr/sup to /var/db/sup?"
- Reply: John Polstra: "Re: Move /usr/sup to /var/db/sup?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: Exporting which partitions to md-configure
... partition table you could look for something like 'Linux_RAID' or similar (just arbitrarily
define some name beginning with the Linux_ prefix), ... This means that the partition
table type would need to be exposed as well. ... To unsubscribe from this list: send the line
"unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo
info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
(Linux-Kernel) - Re: Suse 9.1 Pro fails to boot
... that should be kernel /boot/vmlinuz .... ... If you always put the /boot prefix,
then it doesn't matter whether /boot ... is a separate partition or not. ... (alt.os.linux.suse) - Re: Lockup during boot
... > cvsup of 5.2-CURRENT from this morning. ... I have completed the buildworld,
... > partition which I have been using since sometime back in the days of 2.x ...
> piped to the serial ports so I suppose it could be going to serial console ... (freebsd-current) - Re: Can WinXP Pro format a 160 G Partition with Fat32 correctly?
... "Clark" wrote in message ... > Most Bios can handle the larger drives,
if not an update probably will. ... > WinXP can handle a 160 G partition using NTFS
file system. ... can WinXP correctly format a 160 G partition using Fat 32 ... (microsoft.public.windowsxp.basics)