VFolders isn't a standard yet

[Andreas Pour]

"Raphaël Quinet" wrote:

> > > No, that's not the point.  The point of the vfolders is to be able to CHANGE
> > > the structure without effecting installers, installed programs and programs
> > > that will be installed in the future.
> >
> > What you seem to be describing, to me, is a design flaw in rpm, and
> > perhaps other package mangers.  A package manager that does not permit
> > moving files when installed is really the core problem, no?  And to
> > solve that problem, we create a monster directory with potentially
> > hundreds of files.
> 
> I disagree.  This is a problem of local policies that some sysadmins
> have (especially on large and heterogenous systems) and that can
> probably not be solved adequately by any package manager. [*]
> 
> I administer several networks of Solaris and Linux machines (various
> distros).  Some of them share their applications via NFS, some of them
> have their local copy of the applications.  Some applications are
> compiled from sources, some others are installed from RPM, Debian
> packages or Solaris packages.  I would like the desktop of all
> machines to offer a similar menu structure to all users.  Currently,
> the various distros or source packages do not agree on the menu
> structure (and I would make some changes to it anyway, even if they
> did agree).  If I change the .desktop files after the installation,
> the menus are messed up every time I upgrade a package.  I do not
> think that any package manager would respect my local policies
> regarding the menu structure and still allow the installation, upgrade
> and removal of packages to work correctly.

Hmm, I think I am confused, the way I read this is that you disagree
with my observation that rpm is deficient, because rpm is deficient? 
Each of the drawbacks you list is, the way I see it, based on the
deficiency I noted.

Here's what I have in mind, excuse the syntax, it's not important right
now to get this perfect:

  rpm --modifypackage mv /usr/share/apps/Graphics/gimp.desktop
/usr/share/apps/Applications/gimp.desktop

which  would (1) move the file on the file system, and (2) update the db
to reflect where the file now is.  So, when you do a --verify, or
--uninstall, it verifies / uninstalls
/usr/share/apps/Applications/gimp.desktop, rather than
/usr/share/apps/Graphics/gimp.desktop, where the file was originally
placed.

> 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
;-).
  
> [*] It could be solved by a package manager, but that would probably
>     require some kind of "remapping" file or database that would not
>     be simpler than what is proposed in the VFolders spec.

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.

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.

Moreover, such a change would have universal benefits, not limited to
this very small issue of desktop menus.  It would enable me generally to
move things around on my filesystem, even at install time, something
that rpm currently stubbornly does not permit me to do (I know about
prefixes, that is a hack to address the real issue but, unfortunately,
quite inadequate, as it still imposes the distributor's chosen
heirarchy, even if I can change the base node).

>    Besides,
>     this would only work if all package managers (Solaris, RPM,
>     Debian, ...) as well as the autoconfiscated build scripts would
>     agree on the same syntax for the mapping rules, otherwise it
>     would be necessary to maintain the local policies in many
>     different places.

I guess one will never know, if one does not try.  You can actually do
it with autoinstall scripts as well, e.g. you can implement the "mv X Y"
primitive by adding the command "mv Y X" to a config file for the
package and source that file as the first step in "make uninstall",
thereby restoring all files to the positions they were in immediately
prior to install time (similarly, if you add a new file to a package,
you could just add a "rm -f" line to that file). 

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

Ciao,

Dre