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

Re: Fwd: Re: KDE filesystem structure + metadata



On Tue, Jan 15, 2002 at 12:51:46PM -0800, Oliver Johns wrote:

> On Tuesday 15 January 2002 12:06 pm, David Bishop wrote:
> > Well, if it starts with a "K"..... ;-)
> That's why I suggested that BOTH kde and gnome should be given special
> directory treatment!  Politics!  :-)

If the gnome people want this, they can have it. Why not. The problem is
there are many, many non-gnome GTK apps, and I predict a big debate where
those will go. There aren't many non-KDE Qt applications.
 
> > On a more serious note, that's what dpkg -S /usr/lib/foo.so is for: a
> > quick way to know what belongs to who.
> Yeah, and in windoze, all dlls are in \windows\system and everything is
> in the registry.  Unices are supposed to be easier to maintain, IMHO.  It
> should not be necessary to access some registry in order to see at a
> glance what belongs to who.  At least that should be true for the
> mega-systems like X, kde, and gnome.

There is currently a large discussion (early developent phase) of how to
introduce and "make useful" metadata (EAs, for OS/2 veterans) in Unix
systems, on the ReiserFS mailinglist.

ReiserFS-4 (see www.namesys.com) will get database capabilities and
metadata features in the file system, so apart from the "standard" metadata
attributes like thumbnail icons, comments ("downloaded from...", "last
owner", "Author", ...), flags ("Important", "urgent", "Secret", see MacOS)
and so on it will be able to store package information with the files AND
quickly search for those criteria.

Think a combination of slocate, dpkg -S, dpkg -L etc. as a filesystem
feature, without extra files. Files will be relocatable without problems
(move /usr/doc/* to /usr/share/doc/* and dpkg will still be able to find
files of to-be-removed packages, by searching for the "dpkg.packagename"
and "dpkg.original-filename" attribute for example). 

The big thing however is that (most of) those features will be available
through a (planned) lib-ea, which will emulate them on file systems that
don't support it directly. So you can have it on ext2 or ext3 (or FAT) if
you don't want ReiserFS.  As soon as the standard is stable and developers
agree where (and if) to integrate them in other filesystems lib-ea can be
updated and take advantage of the new features.

If they do it right (and I'm following the discussion closely because I
*want* it done right) this might very well revolutionize package
management, apart from revolutionizing many other features ("where is that
file I downloaded from this website whose title went something like "WaReZ
d0wnl0adz"?).

 
> > The only reason *I* can think of to seperate things is if they start
> > stepping on each other's toes (use the same library, but different and
> > incompatabile versions, but the same major version (it's happened)) and
> > I don't know if it's to that point yet.
> I think it's getting there.  "ls /usr/lib | wc -l" gives 1435 on my
> pretty minimal system.

1974 on my workstation for /usr/bin.
 
> > The only problem I have with the packaging of kde is when I try to
> > compile something like kpilot (to which I contribute very little) and
> > install, I end up having to put stuff into /usr, just to get it to wo..

I usually go along and create a debian package and install THAT, to stay
clean.

> > > Does the Debian policy ever change?
> > Yes, see debian-policy :-)
> Wish it would.  Maybe Daniel or Chris could lobby for it on debian-dev.
> It would sure clean things up for people who want to keep up with both
> kde and gnome.

Yep.
 

-- 
mfg, Jens Benecke
http://www.jensbenecke.de/ - Persönliches
http://www.hitchhikers.de/ - Europas Mitfahrzentrale (car sharing agency)

Politics is like a septic tank - all the big shits float to the top.



Reply to: