Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vollstrecker]

Hi all,
I think it would be great if we had a dir for all the general stuff. The aMule.tmpl file and teh webserver dir could be candidates for this. If I have two user accounts on one machine, I have to have these files in double.
If the users install other files in their home, these files should be taken, but if they want to use the files taht are shipped with amule, the files from the general dir should be taken.
This would take effect in the case, one user has some other files for that purpose, but another wants the original. The files in general dir are updated, but the first user could continue using his own files.
That would be great for packaging too, because the package management should touch userhomes. We could ship amuleweb as rpm (or in my case .deb) without any additional work for the specific users.

MfG usw.

Vollstrecker

[lfroen]

I agree with placing shared stuff to /usr/share/amule. amuleweb (and others) must use local files in .aMule if available, and if not - default to shared location. Splitting rpm is bad idea - amule is not THAT big; and it will just add unnecesary clutter.

[Vollstrecker]

I didn't mean splitting the RPMs, I just want to ship amuleweb, without touching any users home. The debs I'm working on (I know I promissed a long time ago, but debian wants some extra stuff like a manpage for each binary and so on) are splitted, because I don't think anyone should install xas if he doesn't use xchat, so all is splitted and anyone can choose what he wants to install or not. But for these packages I have to ship all neccessary stuff (like the webserver images) but aren't allowed to touch users home.
And I think that you don't have to have the files double, triple or some more times is a good argument to take this step.

[lfroen]

amule/amuled and amuleweb/amulecmd are not independent programs. They are binary incompatable between versions. This means, that amuleweb from version 'a' will crash when started with amule of version 'b'. It doesn't matter what is 'a' and 'b' versions.

So you can split your packages any way you pease (it's free software after all), but I'm strongly advise against. The last thing I want is endless complains on this forum about "amuleweb crashing on startup for no reason".

[phoenix]

lfroen,

With rpms you can include a strict requirement about programs' version, so that if you install version "a", the rpms system does not let you install version "b". The same goes for deb. I see no problem in splitting packages that way.

Also the idea of not touching users home is very good. Amuleweb installation is still unnecessarily complicated.

Cheers!

[lfroen]

Also the idea of not touching users home is very good. Amuleweb installation is still unnecessarily complicated.

Agree.

With rpms you can include a strict requirement about programs' version

By default packagers include ">=" instead of "==" requirement. By splitting packages - you eventually will find users who succeded to mess up the versions. Good luck in supporting them.

[phoenix]

lfroen,

Hey, I agree with you, but we are not the packagers (yet? ) and there are not split rpms or debs around yet. So this should be a strict restriction right from the start, anyone who sees a split rpms without the == requirement, should scream loud!

Packagers can screw a lot, we know that, take a look at wxGTK on almost all major distros. But there is not much we can do about it, besides recommend the strict version equality requirement.

Cheers!

[Vollstrecker]

I make sure, that my pkg's depend on each other, with exact version match. This is one reason why it takes so long to make them. But thats not the topic, and I think, the pics in webserver dir, are compatible with many versions of amule.

[Vollstrecker]

Back to Topic:
Will this (or something similar) be implemented? I didn't read a yes or no or maybe or after 2.0final.
I think it's a good idea and I think others think so too.

[GonoszTopi]

Vollstrecker:

Yes.

After 2.0.0. (final)