[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: What to test for 4.13?
From:       mk-lists () email ! de
Date:       2014-03-16 12:23:35
Message-ID: 9B803879-49E4-4D49-AFE8-B47C54D49149 () email ! de
[Download RAW message or body]

Hi Kevin,

On 16 Mar 2014, at 11:07 , Kevin Krammer <krammer@kde.org> wrote:
> I didn't mean to imply or suggest that the design was flawed or anything =
like =

> that.

ok.


> Ian wrote something about build dependencies and building which kind of d=
idn't go =

> well with my mental model of Mac users.

I see.


> I hardly know any Mac user who would build software so they would not be =

> affected by build dependencies. =


Neither do I, personally I mean.
But there are many on MacPorts!


>> Also one has to point out that MacPorts DELIBERATELY does not distribute
>> port binaries which use code with a licence which isn=92t allowing binary
>> distribution. This is good and considerate design in my eyes.
> =

> Right. Doesn't apply to KDE software but certainly the right thing to do =
in =

> the wider scope.

Hmm, it does apply also to KDE software, since it may use a library which i=
sn=92t permitting binary-only distribution.


>> Yes, it=92s hugely difficult to get KDE applications to build without an=
y X11
>> deps.
> =

> Any idea why? Most applications should not have any X11 dependency, those =

> available on Windows definitely don=92t.

Well, good question!
Unfortunately I am not knowledgeable enough to answer this easily now.
I am busy with all of this since about 3 years and I haven=92t dived into t=
he depths of X11 on MacOSX (XQuartz), Cocoa and the vast dependency tree of=
 MacPorts=92 ports.
I just know that I did my best trying to remove all dependencies to X11 for=
 KMyMoney back then, but had a really hard time, because some tools in thes=
e many dependencies might need some little GTK application or so=85 It=92s =
a major undertaking to unwind all these dependencies and figure out where a=
nd why exactly a certain X11 lib is needed.
But there is a dependency tree view possible for any application. By using =
that one can locate which lib needs what.
An example of that can be seen in my post from March 12th @ 21:31.


>> Well, their philosophy is: OFFER EVERYTHING for the usual OSX user, as
>> up-to-date as possible, so that no-one misses anything later. Back then -
>> when there were no port binaries distributed - this would mean hours and
>> hours and hours of building X11 and Qt and KDE=85 A pain to get started =
with
>> any Qt[34] application, I tell you!
> =

> "usual OSX user" and "hours of building" just don't match in my experienc=
e.
> "hours of building" and "usual user" doesn't match on any platform I know=
 of.

You are absolutely right.
MacPorts doesn=92t target those who can only manage to go to the AppStore a=
nd click on icons.

It=92s merely for geeks, I guess.
But it does a pretty good job already, once you=92ve understood the needed =
workflows.
Their website explains everything sufficiently to get started - if you=92re=
 not afraid of the command line.


> That assumption seemed to have been wrong with Macports actually having p=
re-
> built software and having building as a separate option.

As I said, the pre-built ports came up only a year ago or so, but MacPorts =
is far older.
I think it just shows the evolution of the project. It was time to switch f=
rom solely port building from scratch to binary distribution wherever possi=
ble. And they made it happen. :)


> My updated understanding is now that it is very much like a Linux package =

> repository, where users can just install and run the software without hav=
ing =

> to care about building and dependencies.

Correct, let me cite their website=92s 1st sentence:
<cite>
The MacPorts Project is an open-source community initiative to design an ea=
sy-to-use system for compiling, installing, and upgrading either command-li=
ne, X11 or Aqua based open-source software on the OS X operating system.
</cite>


> Basically a FOSS app store.

Yep, driven by a perhaps a dozen very active MacPorts infrastructure develo=
pers and a few hundred port maintainers.

Have a look at their port repository which contains about 18000 ports! You=
=92d find almost everything you wish for if you have a Linux background. Wh=
en I switched to MacOSX I missed so many tools (Qt, KDE, MySQL, mercurial, =
git, cctools, boost, autojump, doxygen, xsltproc, mc, recode), but MacPorts=
 gave them back to me almost pain-free!

Your system gets updated whenever a port maintainer decides to commit an up=
dated portfile. So, one does not need to worry about how to deinstall old s=
oftware versions from the depths of your iMac=92s file system, but instead =
can sit back and rely on MacPorts=92 logic to keep everything up-to-date, w=
hich generally works fine and with very little interactive user action. The=
 plus is that you usually have stable and up-to-date software installed.

For KMyMoney 4.6 - for instance - there are two ports kmymoney4 and kmymone=
y4-devel. The first is always the latest release version, whereas the devel=
 port distributes a version which I try to keep as close as possible to its=
 git's HEAD version, i.e. is always bleeding edge. The user decides what sh=
e/he wants.

And thanks to the buildbots the MacPorts infrastructure can make sure that =
a a new version of any committed portfile will always be build immediately =
and thus explicitly verify for all four supported versions of MacOSX that t=
he port binaries can be build just fine. THAT is very close to CI, isn=92t =
it?! I mean, it is as good as it can get with just a few build servers, two=
 handful of core devs and dozens or up to a few hundreds of port contributo=
rs.

Greets,
Marko

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]