DragonFly BSD
DragonFly kernel List (threaded) for 2003-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: variant symlinks (was Re: Anybody working on removing sendmail from base?)


From: "Evan Champion" <evanchampion@xxxxxxxxxxx>
Date: Fri, 3 Oct 2003 12:32:04 +1000

While I personally don't have a huge need to have 47 copies of the same
software :-) something I do like the idea of is a variant symlink for /tmp
like:

/tmp -> ${HOME}/tmp

What possibilities would we have there?

Thanks,

Evan

"Mike Porter" <mupi@xxxxxxxxx> wrote in message
news:200310020229.24714.mupi@xxxxxxxxxxxx
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 01 October 2003 08:57 pm, Chris Pressey wrote:
> > On Wed, 1 Oct 2003 17:47:44 -0600
> >
>
> > What if I have users that I don't want to run gcc at all?  Granted,
> > today I would set up groups and make gcc group-executable only - but
> > this VFS-viewfs way seems much more elegant, because they wouldn't even
> > have to know gcc exists.
> >
>
> I wasn't considering this.  however, for those users, even under VFS, all
they
> have to do is 'install' the port (however we define install) and they get
it
> back.  It really isn't any different using symlinks, except...if you have
> already installed all the versions, you can use gids to prevent execution
of
> all installed versions.  VFS could (it seems) simply create a local copy
of
> gcc, in the user's home directory, if necessary, bypassing any
restrictions
> (OK, I guess if the user is putting gcc in their home directory anyway, it
is
> a moot point, they would be able to do THAT regardless of vfs or symlinks.
>
> > > To me, the idea of a program being unavailable
> > > means that no matter what I do as the user, I will never see/know that
> > > the program is installed.  This to me is overkill.
> >
> > It IS overkill, for package management.  But it's not just for package
> > management, right?  Done correctly, it could unify a number of disparate
> > mechanisms currently in place.  chroot, for one.
> >
>
> That's why ultimately doing both is a good idea.  VFS certainly has its
place,
> and will work well for a lot things.  variant symlinks will do a lot of
the
> same things (not all) and should be easier to put in, heck, even I might
be
> able to do it, if I can ever find time (although with my skills, I would
> almost certainly break something first <(}: ).  As matt said, it will
address
> maybe 85% of the cases for VFS, and be easier to put in, should cost less
(in
> terms of performance), and otherwise just seems a good idea.  The other
15%
> still makes VFS worth having, for those who need it, but since varsyms
will
> make things much better, without (in theory) making things any worse than
> currently for those other cases (if it does make things worse, perhaps
> something needs to be addressed, I just don't see how it makes things any
> worse than the current situation, for people you don't want to run gcc?
Just
> break the chain, or create a /usr/local/gcc/9.9 directory, so the code for
> 'latest' will always find that directory, and most of your probelm will go
> away.  Those smart enough to find it, will likely be smart enough to
install
> it from ports anyway.
>
> <(}:
>
> Well, it's way past my bedtime (could you tell? <(}: )
>
> mike
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (FreeBSD)
>
> iD8DBQE/e+HjY30jZzkECLcRApusAJ9MH8YtVwDlrNxh/yrsvwwbO/lkMACfUyjL
> py9/TiDb6LwAGTi1mmxYvu8=
> =iCAH
> -----END PGP SIGNATURE-----
>
>





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