Matt Dillon mentioned that he’s considering using apt-get combined with VFS to create a sort of ‘per-user’ port visibility. Quoting his examples:
“So the ‘apache user’ might only have 10 ports installed (and only access to those 10) while a GUI user might have 50 ports installed (and only access to those 50). Overlaps would be allowed… the environments would be considered independant.
Such environments would also enforce basic isolation/separation/security features such as “/usr is read-only except for /usr/local”, and would be stackable, but instead of trying to use them on a per-package basis we would use them on a per-user basis (or something like that).
This gives us the best of both worlds in my view.
This would mean a new ‘port’ system would have to wait until VFS is finished, though using apt-get without the per-user separation would be achieveable almost immediately.
I’ll admit it. I did not see this coming.
From using various Debian based systems, I can say that I rather like apt-get for doing binary upgrades, but just out of curiosity, why couldn’t the FreeBSD 4.x/DragonFly pkg_* tools just get whatever extra functionality that apt-get has added to it? They don’t seem so dissimilar.
If somebody could enlighten me, I would be greatful.
There are plenty of good solutions possible with different existing tools, and ideas being bandied about on what new tools could be made. What’s needed is for someone to step in and actually do something.
If someone improves the existing pkg tools, or brings in apt-get, it’ll solve the question there because it will have happened. The first person to cross the finish line wins, in this case.
>> I’ll admit it. I did not see this coming.
You aren’t alone; it surpised me as well. I haven’t use apt-get for a pretty long time, so I don’t know how source friendly is in apt-get. I hope, apt-get is a source friendly or maybe DragonFly team can improvement it.
All I can say is… Let’s wait and see how it goes…in the next months.
I’d like to say more, but I’d have to have an actual insight, first. Thus…
Obvious good:
-Not reinventing a wheel without being sure it has staying power (not inflicting the next RPM or Portsalike-but-not-quite on the community, except in so far as apt might be considered the second by some…)
-Segregation by user is deterministic; you know who you’re logged in as, and if you don’t, there are ‘familiar’ tools to tell you.
-Yet another way to impose ACL-type functionality?, but one that’s intended to be a consistent piece of magic in DragonFly.
Maybe not so good:
-User logins are ‘modal,’ and in theory, laziness may triumph as much as build-as-root is still a practice. This doesn’t necessarily inflict harm except as we’re no more secure than where we started… but it also makes the case of one user flipflopping between, say, two versions of Mozilla that little bit more complicated. (Down to implementation details either way you look at it, true.)
-Religious wars start easily, but if you have to start applying ‘less than least-surprising’ semantics to /usr/local, is it time to start thinking about a /opt or /local, and/or the proverbial “/System Folder” that ‘normal humans’ may or may not really find more straightforward? This said with a straight face, while recognizing that keeping the status quo is good for compatibility and thus for DragonFly, and that everyone’s pet ‘post-filesystem’ projects will probably eventually cough up something that puts both ‘multiple roots’ and/or the related (and possibly half-baked, sure) idea of Amiga volumes and assigns to shame.
It does sound reasonable, but so did my interpretations of previous plans, so I’m going to wonder if people won’t always want both… and of course, when per-user anything conflicts with per-package anything, you get what I think they call “a right mess.” … If it’s what makes sense for 1.x, and everyone carries on in the spirit of building more bridges than are burnt (Hm, pkgsrc to apt and back someday, if it would ever prove useful? Does that even make sense?), more power to it?
[The appropriate research is going on my to-do list, I just had to play devil’s advocate for the reasons mortals find ‘*NIX’ ‘crazy.’ Obviously there’s only so much anyone can do and so many bikesheds that can be painted in a year, and some such things might best be pushed to other levels of the stack… Mozilla1 could be setuid one user and Somehow_Conflicty_Mozilla2 another, for instance, if nothing else, and then it’s all the display server’s problem? ;}]
My apologies if all this and more has already played out on -kernel.