VFolders isn't a standard yet

[George]

On Tue, Jul 09, 2002 at 02:28:23AM -0500, Andreas Pour wrote:
> > The VFolders spec may be a solution to that problem.  Maybe not the
> > best solution, but at least I hope that it would allow me to upgrade
> > some packages without having to do a lot of manual work.
> 
> Right, I agree, that this is a hack around the package manager
> deficiencies, and, as such, provides a solution, if not an appealing one
> ;-).

1) You cannot modify all packages at once, even if your proposed change
   did make sense to them.  Not to mention that it's not just package
   managed systems that are affected
2) Even with your setup, an installer will get the initial location wrong
   once the hierarchy has been changed on a system (which is one of the
   biggest reasons for vfolders)
3) Your solution is a lot more complex and a lot more fragile then
   vfolders
4) Your solution solves one small problem and leaves all the other issues
   that Vfolders solve untouched.

> Whether it's simpler or not depends on the code.  If, for example, MySQL
> were used instead of DBM for the database, it would be a trivial UPDATE
> query.  I presume that this would not be difficult with DBM, in the
> worst case, it would seem, you would have to do a delete and add rather
> than an update, but DMB *is* a database.

Complexity doesn't just come from modifying the package manager.  It also
comes from having everything that moves files also notify it.  So you need to
update everything that wants to move files.  Or you dump the complexity on
the sysadmin in which case most sysadmins won't bother, and you have a broken
system.  You must also track the locations of the files relative to their old
mapping so that you can update software properly.

> If that is the case, IMHO, writing some short code to recognize the new
> switch, and based on that doing an "UPDATE" query, is quite a bit
> simpler, than the proposal you have made, save perhaps for making the
> two changes atomic, though I presume RPM already has some mechanism in
> place for that.

I had a basic vfolder system in place in about a day.  So the proposal IS
simple.  The code to read and display menus from a directory structure
is quite a bit more complex.

> I realize this discussion is a bit off-topic, since it is pretty clear
> that such a change cannot be implemented in reasonable time, but,
> hopefully soon, the root problem will be addressed b/c, positive
> benefits aside, it is quite a mess to throw all those files in one
> directory (maybe your syadmin likes it, but the home user, I think, will
> not and I know for sure, that I will not).

Huh?  99% of home users will not even know there's a single directory
because they don't care, they only see their menus.  There are other huge
directories (/usr/bin or /usr/lib for example) that you are not trying
to change, why?

George

-- 
George <jirka at 5z.com>
   You can't say civilization isn't advancing: in every war they kill you
   in a new way.
                       -- Will Rogers