Print

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

[thepolish]

Hi,

A new poll to determine how to split amule rpms

Kry said let amule + ed2k together

One question is should we split from dependencies, ie wxBase tools (cmd line) and wxGTK tools (GUI tools) ?

An other, should webserver be splitted from other tools ?

the polish

[Jacobo221]

I vote for 1.

I completely disagree with options 2 and 2 because of two reasons:
 - First, I don't quite see the point in having both GUI and non-GUI utlities installed at the same time. In most cases, either you use the GUI or the non-GUI app :-)
 - Second, having aMuleWeb in a different package from aMuleCMD or, in the worst case, having aMuleCMD considered as a "non-useful" remote aMule administartor is an error from the point that in some future, aMuleCMD should be improved to be as feature-rich as aMuleWeb (from what code reads, ir seems to me like shakraw is already working on that). aMuleCMD would be the interface with aMule in a future were core and GUI are splitted. In a not-so-far future, aMuleCMD would be the interface with all those ssh aMule users who are claiming for aMuleCMD to be "useful" ;-) So, having future in mind, I think aMuleWeb and aMuleCMD should be considered as "the same" in functional terms.
My secondary vote would be number 4, though (all or nothing, hehe ;-) )

[thepolish]

Hi,

just to refresh poll

the polish

[GhePeU]

voted 4

I think that a functional division is best choice

1) (amule + ed2k) core program

2) (amuleweb, amulewebDLG, amulecmd, amulecmdDLG) remote control

3) (cas, wxcas) statistics


2) and 3) are optionals, and if someone need remote control he can choose between gui and cli tools without installing different packages and by the way someone could be interested in statistics (cas, wxcas) but not in controlling amule from another machine

[bootstrap]

Well - i normally don't call other peoples ideas stupid, but splitting the webserver into 2 pieces is exactly that.

The main problem is that amuleweb and amulewebDLG depend on the same core files. To split up the binaries into 2 pieces is simply impossible without breaking up the packaging.

I don't know how you would like to solve that, but i don't create packages that ship files twice.

This leaves only one logical choice for splitting - based on function, not gui/commandline.
That would give us a base package "aMule" the "tools" (cas/wxcas/amulecmd/amulecmdDLG) and a webserver package.

This is easy to split - easy to maintain - and even easy to understand.


Actually there's a second choice - building even more packages like in #2.
That would also work, but is it really needed to split the tools into 2 packages? I mean - did you ever count the bytes you would save by removing the gui-tools?
Anyway - that could be an option.



Just imagine a user that just don't wants the webserver - should he drop cas because he doesn't want the webserver?

I don't think so.

Currently i'm building my cvs rpms into 4 packages - aMule/tools/webserver/debuginfo and i keep doing that. Once the next release is ready we should have a decision that leaves us a package that works - not a group of packages that look nice.

Comments welcome.

[Jacobo221]

> Currently i'm building my cvs rpms into 4 packages - aMule/tools/webserver/debuginfo

Looks OK to me. And you're right on the core/GUI/command issue, I hadn't notice.

[thepolish]

Hi,

When re-thinking to it, my prefered choice is: (amule+ed2k) + web(amulewebDLG+amuleweb) + cmd-tools(amulecmd + cas) + gui-tools(amulecmdDLG+wxcas)

- 1. webserver is in 1 packages
- 2.  GUI tools and cmd tools are splitted

Why split tools ? Not to save bytes... But just in the case of an user want to install cmd tools, not on the pc where amule is running, but on a remote pc to monitor remote amule.

So he could install cmd tools without depending on X packages and GTK and wxGTK, only wxbase. So less dependencies for cmd packages

the polish

[dePOLL]

I totally agree with thepolish

[cdb]

I don't really know what all that stuff is... and to be fair, it does not really interest me as a user...

All I want it to do is work properly (as it does). I use the GUI and I did not even know there was a web-app or a CMD build in or a seperate core, for that matter....

As a user I am interested to download quicker then anybody else, with a programm smaller then everybody elses....

What I would like (but what does not really bother me) is multi server support, for a larger "local" search area.

For me it would be best to strip the program down to core/GUI only... but I do realise that some people could be quite fond of the web-site type of connection...

[xit]

What about amuled.
If something must be split i thing it's it.
Most people using amuled look for a "slim" app.

xit

[lfroen]

In ideal, perfect world I would not want anything splitted. Why ? most of programs like amulecmd, amuleweb are very small so splitting doesn't have match sense.

Our world is not perfect, however, and there's parts of amule that require X and gtk, and there's another part  that doesn't require.  This is only one truly technical reason for split.
So, under this condition we should have [ amule+(*-DLG)+amulegui  ] and other [ amuled amulecmd amuleweb ed2k and other cli]

[xit]

totally agree with you lfroen

[deltaHF]

well.. the thread is out-of-date .. someone wanted to split the rpms and we decided that we don't do it.

cheers

ps. closed