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

Re: VFolders isn't a standard yet

 --- George <jirka 5z com> wrote: > 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
> > 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
> > 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
> 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).

having the various desktop files in various directories is a
nightmare for non-developers to get a grasp of the system so they can
use and understand it.

Why should there be a problem with naming, surely there should not be
very many desktop files per application?

In addition it is a lot easier to find a desktop file in one
directory rather than running a series of locate/find|grep commands

> 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 5z com>
> You can't say civilization isn't advancing: in every war they
> kill you
> in a new way.
> -- Will Rogers

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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