| |||||||||||||
|
| |||||||||||||
Repositioning the KDE Brand (KDE.News)Repositioning the KDE Brand (KDE.News)Posted Nov 26, 2009 20:02 UTC (Thu) by dkite (guest, #4577)In reply to: Repositioning the KDE Brand (KDE.News) by JoeF Parent article: Repositioning the KDE Brand (KDE.News)
>Decoupling means I can download a kopete package, and it runs. I shouldn't
have to go and download or compile the whole kdelibs, kdepimlibs and kde- support stuff, with all the dependencies that entails (boost, etc. etc.)
Are you suggesting that
Try building something like gnucash. Same issue. I would rather the
This isn't a KDE issue.
Derek
(Log in to post comments)
Repositioning the KDE Brand (KDE.News) Posted Nov 26, 2009 21:44 UTC (Thu) by JoeF (guest, #4486) [Link]
It is about minimizing the dependencies. Kopete probably only uses a small fraction of the stuff in kdelibs.
And if it was packaged on its own, like pidgin, it would have to have the required libraries and _only_ the required libraries with it. That doesn't mean that it has to be statically linked. That's a non-sequitur. In fact, I was rather surprised that kopete wasn't a separate download. It for sure isn't a core component or KDE, so why in the world would it only be available as bundle with all the other kde stuff? Even in kdenetwork, there is a whole bunch of stuff in there that has nothing at all to do with each other, except that it is somehow network-related.
And again, the whole issue is not about kopete per se, but about the fact that at this point, there isn't all that much decoupling, making the name change stuff just some marketing BS.
Repositioning the KDE Brand (KDE.News) Posted Nov 26, 2009 22:20 UTC (Thu) by aseigo (guest, #18394) [Link]
"Kopete probably only uses a small fraction of the stuff in kdelibs.
And if it was packaged on its own, like pidgin, it would have to have the required libraries and _only_ the required libraries with it."
This is what most distributions offer, in fact. Exactly, and precisely.
"In fact, I was rather surprised that kopete wasn't a separate download. It for sure isn't a core component or KDE, so why in the world would it only be available as bundle with all the other kde stuff?"
Good question; we offer the source code for those who would like to build it. Most of our users get it from our distributors, in your case that's Slackware. For those who decide to grab the sources and build, we've found that people appreciate being able to grab a representative "basic set" of tools for a given topic. For more advanced tools or vertical applications, we put those in Extragear and they are, indeed, shipped completely on their own.
Each item in the package that Kopete is in is buildable separately, however. You can configure the top level module and then simply cd into the kopete directory and build it from there. You don't need to build or install anything else in the KDE Network module / basic application set. The bundling of the sources is simply a convenience, one many of our from-source users appreciate.
However, many KDE distributors (most, in fact) split those packages up into smaller chunks, so that Kopete, for instance, appears on its own. Let me give you a practical example from OpenSUSE:
independence:~ # zypper search kopete
S | Name | Summary | Type
As you can see, there is both Kopete built using the 3 and 4 versions of the KDE dev platform. Even one of the protocols (facebook) is broken out into its own package in this case. I can install one or all of those packages and everything is handled for me. If I wanted the version of Kopete from KDE SC 4.3 but I was using the KDE 3 desktop, I could just do "zypper install kde4-kopete" and Kopete along with the needed libraries would be installed (and nothing else; not the rest of kdenetork, not the KDE Plasma Desktop .. just the KDE 4 Dev Platform and other libraries that Kopete may use). I can even install the development headers so I can build third party plugins for Kopete from sources if I wish.
KDE makes this possible by ensuring that the apps in the main modules are buildable separately and by shipping all the non-"basic set" applications individually from Extragear. Distributors make this possible by making sound decisions for their end users.
Not all distributors will package things this way, of course, and that's one of the things about freedom: different people will do it different ways according to their needs, and those needs may not be yours. If Slackware doesn't package things the way you need them to then use someone else as your KDE distributor. (I know many people for whom Slackware does it "just right", so this isn't a slam on Slackware in any way. :)
None of this has anything, whatsoever, to do with the KDE rebranding, other than that the rebranding makes the KDE communication match the reality of what actually happens. e.g. Kopete available separately from the Plasma Workspace.
(As a thought experiment, how do you think it works on MacOS or Windows? :)
"What they should have done is actually _do_ the decoupling, and _then_ announce it."
Can we agree on this: let's ensure you have all your facts straight, and THEN let's hear what you think we should do? That seems to be the logical, not to mention the responsible, way to go about this.
Repositioning the KDE Brand (KDE.News) Posted Nov 30, 2009 6:22 UTC (Mon) by JoeF (guest, #4486) [Link] For those who decide to grab the sources and build, we've found that people appreciate being able to grab a representative "basic set" of tools for a given topic.Well, then count me as one who doesn't appreciate that. I'd like to be able to just grab the sources I need to compile and run one program, e.g., kopete. Can we agree on this: let's ensure you have all your facts straight, and THEN let's hear what you think we should do? That seems to be the logical, not to mention the responsible, way to go about this.
Repositioning the KDE Brand (KDE.News) Posted Nov 30, 2009 15:36 UTC (Mon) by foom (subscriber, #14868) [Link] Your problem appears to be with the source code layout of KDE, something that, quite frankly, doesn't matter for 99% of users. So it's rather silly to hear you complain so vociferously that their marketing is incorrect, when you're probably one of the only people in the world who both 1) builds from source 2) cares how big it is.If you find compiling from source that horrendous, I'd recommend using a package manager to install your software, where the libraries and apps have already been split off into individual pieces. And let the KDE people lay out their source code however they find easiest for *development*.
Repositioning the KDE Brand -- v-- Build from source Posted Dec 3, 2009 20:39 UTC (Thu) by brianomahoney (subscriber, #6206) [Link]
No, once again nonsense:
What I am really tired of is the 3-4 major sub-projects that an Open-Source distribution depends on eg: (1) KDE (2) Mozilla (3) OOO (4) Java/Mono which seem unable to (a) package their source, (b) provide a convenient build system, (c) list dependancies realistically.
I am all for innovation but do we really need UNDOCUMENTED uses of autoX, libtool, cmake, ant, python 'pyXXX' and many more ... all of which don't come outr of a SVN or GIT download and neet to be stitched together by hand with pre, co and postrequisites before you can say 'make' or whatever?
NO, this is sloppy junk, and BTW Google should stop adding to this mess with Chrome and Android.
Repositioning the KDE Brand -- v-- Build from source Posted Dec 4, 2009 1:11 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, for KDE and Mozilla your points are wholly baseless.
The build system for Mozilla is a pretty boring Autoconf/Automake thing,
The cmake and autoconf-driven build systems of Mzilla and KDE4 are
My autobuilder scripts for both KDE and Mozilla are less than two dozen
Both Mozilla and KDE list their dependencies: KDE does so, again, to an
Your belief that generated files like configure scripts et al should be
Now, OOo is a sodding nightmare, I'll agree with that. Any project that
|
|
||||||||||||