Re: VFolders isn't a standard yet

[Mike Martin <redtuxxx yahoo co uk>]

 --- 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 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).

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
> 
> 
> 
> _______________________________________________
> Xdg-list mailing list
> Xdg-list freedesktop org
> https://listman.redhat.com/mailman/listinfo/xdg-list 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com