look in the PKGBUILD. there are some comments on why they are there.

depends=('ecore-svn' 'gnome-menus' 'gnome-icon-theme')
# gnome-menus is needed for /etc/xdg/menus/applications.menu
# gnome-icon-theme is needed for e17 to use a backup icon theme

those are e17 dependencies, not efreet ones

@Ronald van Haren You explicitely say that those dependencies are requested by a windows manager and not by efreet.

As an Enlightenment developper, I confirm that efreet does *not* depend on gnome stuff. Also, why choosing gnome icons and not Tango ones for example ?

I said that the window manager calls efreet and that it is further handles by efreet, at least that was my understanding from the description. To be honest I haven't looked at the code, so if this isn't the case please prove me wrong.

I'm still not sure why you would want to classify a bunch of pictures and text files as gnome stuff, other than that it has gnome in its name.

Why gnome icons instead of another one? I never tried another one, but if I had chosen another one you could ask a similar question. It is not that it pulls in any other gnome dependencies AFAIK.

Thank you for reopening the task.

Hmm, did you see all the dependencies of gnome menu ? pygtk, libglade, gtk+, etc... For the gnome icon theme, gtk+ is a dependency. That's just too much for a libraries that tries to just read some freedesktop specification files (trash, mimetypes, desktop, etc...). Its purpose is to read some configuration files. It does not need them. Those files are at the desktop level, that is, the windows manager or the desktop environment (like KDE or Gnome)

From the Efreet README:

"
An implementation of several specifications from freedesktop.org intended for
use in Enlightenment DR17 (e17) and other applications using the Enlightenment
Foundation Libraries (EFL). Currently, the following specifications are
included:
* Base Directory
* Desktop Entry
* Icon Theme
* Menu
* Trash
* Mime
"

I give you the links:

http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
http://www.ramendik.ru/docs/trashspec.html

So freedesktop tries to unify the desktops by saying how the trash should be managed, how the icons should be named and managed, etc... Efreet is a libraries that implements those specifications. That's all.

We try to be lean, light and fast. If some big dependencies are added, then all our purposes are useless.

For example, Elementary (the widget toolkit based on the EFL) can use Efreet. So having gtk as a dependency is a really weird :-)

>> Hmm, did you see all the dependencies of gnome menu ? pygtk, libglade, gtk+, etc... For the gnome icon theme, gtk+ is a dependency. That's just too much for a libraries that tries to just read some freedesktop specification files (trash, mimetypes, desktop, etc...). Its purpose is to read some configuration files. It does not need them. Those files are at the desktop level, that is, the windows manager or the desktop environment (like KDE or Gnome)

I'm not sure your point is where these deps are located, but more the point that they are. For example KDE provides the application.menu file within kdelibs, which likely provides a similar function as Efreet does. Anyway, I don't have a strong opinion where the deps should be located. I can move the deps to the main enlightenment wm package but I hardly doubt that would solve your concerns.

Anyway, it is my understanding that Efreet only reads applications.menu and it is not possible to configure it to read something like e-applications.menu (assuming this is still the behavior?). That would mean we can't ship our own applications.menu as we would need to conflict with gnome which doesn't make sense. Not shipping one means an empty menu which also doesn't seem to be the intended behavior.
Then again, if we could just ship enlightenment to read something like e-applications.menu we could ship that file and the gnome-menus problem seems mostly solved.

For gnome-icons I need to check when I have time, I will comment on that at some later time.

>>We try to be lean, light and fast. If some big dependencies are added, then all our purposes are useless.
Sure it could be trimmed down a bit if we could solve the menu problem. These deps however won't affect performance at all by being installed as they are not used (assuming you don't run the included menu editor).

I'll remove gnome-menus and add an e-applications.menu file to e-svn. That seems to work just fine.
I'll also remove the icon theme dep. If you guys want it packaged without a default icon theme, than I don't mind.

Is this something you can agree with?