| |||||||||||||
|
| |||||||||||||
Repositioning the KDE Brand (KDE.News)Repositioning the KDE Brand (KDE.News)Posted Nov 26, 2009 13:30 UTC (Thu) by jospoortvliet (subscriber, #33164)In reply to: Repositioning the KDE Brand (KDE.News) by nye Parent article: Repositioning the KDE Brand (KDE.News)
We can't help packaging bugs. Any KDE app works anywhere if it is properly packaged. Even on win and Mac. 'KDE 3.5' doesn't influence the apps which work in there - to non-KDE-3.5 apps it acts as a mere windowmanager.
(Log in to post comments)
Repositioning the KDE Brand (KDE.News) Posted Nov 27, 2009 2:45 UTC (Fri) by lysse (guest, #3190) [Link]
> We can't help packaging bugs. Any KDE app works anywhere if it is properly packaged.
Yes, but that phrase - "properly packaged" - covers a vast and growing multitude of sins. If something depends on 500 different libraries, then I'd say claiming that anyone who found it impossible to get all 500 in sync was at fault for not using a properly packaged version of that something is a huge abrogation of responsibility.
And whilst I don't use KDE - haven't for years; never really got on with it, and I'm not demanding enough of my desktops to warrant it - this is becoming an increasing problem with *everything* in the FOSS ecosystem. I've seen non-beta releases that don't even bother packaging up their in-house dependencies properly! And I'm sick of a situation that's got way, WAY worse than DLL Hell ever was, and is ludicrously worse than Windows is today - and frankly, this idea that you can shrug off any and all responsibility for not making your shit compile properly by carping "proper package!" has been a massive contributory factor.
Sorry, did you want constructive criticism? Well, here's a suggestion - if you're shipping a source package, then at least make your config/build systems capable of fetching and default-building any missing dependencies statically, automatically, within the same damned source tree! Anything less than that is just an abrogation of the responsibility of going beyond works-for-me that you implicitly accept when you seek other users for your software. Honestly, it's the software equivalent of learning that houses are not just magically tidied up by the cleaning fairy a few moments before guests arrive...
Repositioning the KDE Brand (KDE.News) Posted Nov 27, 2009 2:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
please name a single program which has it's build system setup to fetch the source code for all libraries that it depends on, configure them, and build them when you try to build the program
nothing does this, and there are good reasons why this is so.
do you want the developers tracking the details of all the libraries that they use, where to get them, how to configure them appropriately (for all different platforms no less), how to install them without conflicts on every distro out there, etc.
or do you want them working on improving their application and documenting that they need library X (version > y, tested up through version z) and let the users or distro maintainers pull, configure, and install the appropriate libraries?
personally, I want the developers to work on their own app.
kdesvn-build Posted Nov 27, 2009 3:44 UTC (Fri) by sbishop (guest, #33061) [Link] please name a single program which has it's build system setup to fetch the source code for all libraries that it depends on, configure them, and build them when you try to build the program KDE, funny enough: http://kdesvn- build.kde.org/. I've used it on old RHEL systems to build a decent, up- to-date KDE. It was nice to have everything taken care of for me.
kdesvn-build Posted Nov 27, 2009 4:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
WOW, you mean that it will fetch the code for glibc and compile it if the development packages are not already installed on the system? what about PAM libraries?
I suspect that the most it did was to grab other KDE specific libraries.
kdesvn-build Posted Nov 29, 2009 18:17 UTC (Sun) by sbishop (guest, #33061) [Link]
glibc and PAM, huh? Well, you need to be careful. If you have the script handle the user-space component of your operating system, it must, of course, handle the kernel-space component as well. You will, if I remember right, end up running FreeBSD. (It's pretty popular with the KDE devs.)
Typically, however, kdesvn-build will only build and install Qt, taglib, CMake, and QCA, among others.
Repositioning the KDE Brand (KDE.News) Posted Nov 27, 2009 3:14 UTC (Fri) by foom (subscriber, #14868) [Link]
> Honestly, it's the software equivalent of learning that houses are not just magically tidied
> up by the cleaning fairy a few moments before guests arrive...
My software house *is* magically tidied up -- Debian unstable or experimental generally has recent
Repositioning the KDE Brand (KDE.News) Posted Nov 27, 2009 7:00 UTC (Fri) by nix (subscriber, #2304) [Link]
You want everything's build systems to learn how to autobuild glibc for
you if your version is too old?! If not that, then where do you stop?
Repositioning the KDE Brand (KDE.News) Posted Nov 27, 2009 13:02 UTC (Fri) by lysse (guest, #3190) [Link]
The thing about rants (well, mine anyway) is that they're (a) born of deep
frustration, and (b) not necessarily 100% thought through, especially when it comes to solutions.
|
|
||||||||||||