[KDE/Mac] Re: CMake to deploy package for Mac (Re: Developing KDE on Mac)

[Mike McQuaid]

On 5 Oct 2010, at 16:21, Bernhard Reiter wrote:

> I would expect Macports/Fink already having a solution for maintaining
> one time services.

They are just package managers. You can install D-Bus and then call launchd to have it as a system service.

> Given that we use code under GNU LGPL and GNU GPL I guess we should provide
> the full source code to comply with the license.

I still don't really understand the problem here, you just provide the source code of your dependencies?

> I consider this a (minor) drawback, a reproducable rebuild will take a lot of 
> time and probably include all source files. A packaging system can make this 
> build reproducable after installing 30 packages.

How often, realistically, are you going to be pushing new versions of Qt?

> I agree that it is the same problem on windows.
> 
> Usually the time is not there to optimise and often it cannot be done 
> automatically. On Windows we ended up with several hundereds of Mebibytes
> being installed, up to one Gibibyte. And then we should think more than 10 
> Free Software applictions, so disc space can still be an issue.
> But you are right in that it is going to be less and less an issue.

The "correct" way if you want to do it like that on Windows is to use MSI and side-by-side assemblies. The problem isn't that there isn't enough time to optimise but that it's normally not worth it. If you are installing 10 free software applications on a machine, you are a distributor, not a typical end-user.

> I agree that this is a drawback, but I consider it minor.
> 
> This works the other way round for me: If a library is shared by several 
> applications, I would expect they also share an insterest to keep the quality 
> high, so they are sharing stabilisation work on the library.
> As when you have your own version, that common interest is much lower
> or would need to take place over designated source code revisions.

That's not the case when you are deploying single pieces of software. You are coming from the viewpoint that most users will want to install a "suite" of tools. This doesn't reflect the use case of most Windows or Mac users, they tend to install single GUI packages at a time.

> Well I am trying to think all aspects together. So I recognise that doing it 
> the common Mac way will be best. I am not entirely sure for Mac, but for 
> Windows we've found this much harder to support one installer then it was to 
> support the installation on GNU systems with nice package management. We 
> still did the installer, but involvment by other community members is very 
> low. I would like to join a strong community and the Free Software community
> for Mac seems to be strongest in MacPorts and Fink. (As far as I know.).

That's simply not the case. Macports and Fink are the strongest single distribution channels but they do very, very little actual development of free software. Even then, they are mostly only used for command-line applications or for applications that don't have native installers yet.

The most commonly used free software on Mac are things like Chromium, Adium, Firefox, Thunderbird, Tweetdeck. None of these are installed using a package manager.

> I guess you would need to bring up your arguments within those initiatives
> to convince them.

> Those are two different issues, currently we need to get a development, 
> release and upgrade process going that allows for a beta quality or better 
> Kontact to be installable at all. So we do not have that yet, no matter how 
> we package it. Using Macports/Fink now, will solve part of the installer 
> problem so we could concentrate to get the quality of the software better.
> Once we reach that status, I agree that we should think about doing a single 
> installer for Kontact (Enterprise 5). So there is a time factor at play.
> To me, now doing much installer work is spending the time at the wrong place.
> This can be done later.

We already have the installer problem sorted, you can already install using Macports or Fink, you just need to use the commandline or one of the already available GUIs. 

If you think doing installer work now is a bad use of time then don't do so but please don't critique others who want to do so. I don't believe KDE on Mac will be better until we attract more contributors and I think an essential part of that is having the ease of installation and the stability of drag-and-drop binary packages that OSX users are familiar with.


On 5 Oct 2010, at 16:25, Bernhard Reiter wrote:

> I think porticus is non-free [1].
> So it does not give us enough control.
> 
>> http://finkcommander.sourceforge.net/
>> 
>> They already exist. I don't know anyone who uses them. I'm not sure what
>> the advantage is of creating one from scratch that looks like an installer.
> 
> That is a question for Sjors, I think. :)

Well, it's also a question for you if you are suggesting Sjors solution over using CPack.

> I understood the Fink developer in a different way: He saw problems if just a 
> few packages are installed by something else that creates a conflict with the 
> fink packaging solution. I am assuming a frontend that does not create a 
> conflict, Hildon application manager is an example that does this reasonably 
> well. So it is possible.

We'll agree to disagree here but at least one Fink developer has said he thinks CPack would be a good solution.



On 5 Oct 2010, at 16:43, Bernhard Reiter wrote:

> Ah, Homebrew is new to me. 
> (Again I do not know much about Mac "installation".)
> 
> http://abhinay.wordpress.com/2010/01/02/macports-to-homebrew-new-packaging-system-for-mac-os-x/
> http://mxcl.github.com/homebrew/

I'm a core contributor to Homebrew.

> You are essentially saying that the Fink, Homebrew and Macports people have 
> been on the wrong track with many of their applications as they should have 
> rather used CPack and build infrastructure for it. From the outside, they 
> still are a bigger community than you are.

That's not what I'm saying at all. What I'm saying is that they are inferior methods of distributing GUI applications and that CPack offers us a chance to solve this problem. If you look at how many Mac users have a piece of free software installed on their machine (again e.g. Firefox/Chrome) and how many used Macports/Fink/Homebrew compared to native drag-and-drop application bundles, you'll see that far, far more people use the native way. Homebrew, for example, doesn't add any packages for GUI applications that already have native installers. There is a reason for this.

> Currently we do not have a significant developers community nor do we have a 
> user community. As outlined in my other post, not being deeply involved, I am 
> seeking for a big Free Software community and infrastructure that I can 
> strengthen and be a part of. If we get macports or fink maintainers to buy 
> into KDE applications via their "packaging" efforts, we win over more members 
> that share the same source. Otherwise it looks like we are a far smaller 
> group.

Again, they already "buy into" KDE applications. They are installable using those methods but yet many KDE developers don't use KDE on their Macs (me included) because the Macports/Fink solutions aren't good enough.

> Because it is about having running code first and improving the code of the 
> libraries and applications itself first. Installation hurdles are there but 
> can be overcome by a significant fraction of users (it seems that even more 
> than 10% of people jailbreak their iPhone). Lacking quality of the 
> application itself cannot be overcome unless you are a Mac and KDE 
> superhacker like Till. So I'd rather direct all energy that there is towards 
> making the application itself run and share the difficulties of all Macport 
> users. If Sjors does an frontend for their packaging system, cool that eases 
> the pain for all of Macports or Fink. It benefits much more people than just 
> KDE.

The applications do run. There are already GUI front-ends. I'm not sure how another GUI installer will fix anything.

> http://guide.macports.org/#using.binaries
>  3.4. Port Binaries
>  MacPorts can pre-compile ports into binaries so applications need not be 
>  compiled when installing on a target system. 

Good to know.


--
Cheers,
Mike McQuaid
http://mikemcquaid.com