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

Am Freitag, 1. Oktober 2010 15:15:33 schrieb Mike McQuaid:
> > * Running an stopping various processes (like dbus) that should be
> > unique?
>
> CPack doesn't solve this issue, you need to solve it yourself. D-Bus could
> be either installed a system dependency (perhaps with KDELibs) or we can
> just run a local D-Bus instance if it is needed on application creation.

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

> > * The rebuilding of the complete source code, once I have it?
>
> That's the advantage of the CPack solution. If done properly, all it should
> require is "make package" to build the software and a redistributable
> package. I don't think we need to build Qt. I'm not aware of any other KDE
> distribution that supplies all source dependencies in one location.

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.

> > * Updates of a part of the dependencies do require a complete and full
> >  rebuild? (Because we cannot be sure that rebuilding works until it has
> >  been done successfully first and no intermediate step can reconstructed
> >  reliably.)
>
> You would create a new package if you wanted to use a new version of Qt.

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.

> > Potentially there are hundreds of interesting Free Software applications
> > for Mac, at some point being able to use shared resource will have an
> > significant effect.
>
> On Windows, do you install Qt into C:\Windows\System32? If not, why not?

I agree that it is the same problem on windows.

> With respect, people who insist on sharing libraries like this don't the
> way software is usually distributed on Mac or Windows. The reason you don't
> share libraries is because the hard disk requirements are small enough to
> be inconsequential. With the above example, if you're talking about maybe
> 15MB of Qt libraries per application (I'm sure I could optimise that
> further) when the average size of hard disk on new machines is 500GB. It
> really doesn't matter if they are duplicated 10 times.

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.

> Fundamentally, Apple don't recommend deploying applications like that. The
> users don't want to worry about installing and uninstalling applications in
> some new way so the libraries are shared. 

I agree that this is a drawback, but I consider it minor.

> The developers' lives are made 
> much easier when they only need to support a single version of Qt, D-Bus
> and KDELibs rather than this being updated when the user installs a new
> piece of software.

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.

> I know this is free software but looking at the way Linux does things and
> trying to apply it to Mac and Windows is the wrong way round. If you want
> to produce software that your users will want to use, you want to do things
> in the way they expect it to behave on that platform. This much is basic
> HCI and it's why Qt spends so much time trying to do the most sensible
> native behaviour on each platform.

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.).

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

> If we make it much harder to install Kontact than Thunderbird (which pretty
> much every proposal other than the CPack one does) then users will not use
> Kontact. This is why I don't use Kontact as my mail client at the moment
> and why many of the KDE on Mac people don't do so either: because it's a
> significant burden on the users to attempt to use it in Macports/Fink
> compared to native clients.

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.

Best Regards,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Am Freitag, 1. Oktober 2010 15:15:33 schrieb Mike McQuaid:
> > * Running an stopping various processes (like dbus) that should be
> > unique?
>
> CPack doesn't solve this issue, you need to solve it yourself. D-Bus could
> be either installed a system dependency (perhaps with KDELibs) or we can
> just run a local D-Bus instance if it is needed on application creation.

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

> > * The rebuilding of the complete source code, once I have it?
>
> That's the advantage of the CPack solution. If done properly, all it should
> require is "make package" to build the software and a redistributable
> package. I don't think we need to build Qt. I'm not aware of any other KDE
> distribution that supplies all source dependencies in one location.

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.

> > * Updates of a part of the dependencies do require a complete and full
> >  rebuild? (Because we cannot be sure that rebuilding works until it has
> >  been done successfully first and no intermediate step can reconstructed
> >  reliably.)
>
> You would create a new package if you wanted to use a new version of Qt.

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.

> > Potentially there are hundreds of interesting Free Software applications
> > for Mac, at some point being able to use shared resource will have an
> > significant effect.
>
> On Windows, do you install Qt into C:\Windows\System32? If not, why not?

I agree that it is the same problem on windows.

> With respect, people who insist on sharing libraries like this don't the
> way software is usually distributed on Mac or Windows. The reason you don't
> share libraries is because the hard disk requirements are small enough to
> be inconsequential. With the above example, if you're talking about maybe
> 15MB of Qt libraries per application (I'm sure I could optimise that
> further) when the average size of hard disk on new machines is 500GB. It
> really doesn't matter if they are duplicated 10 times.

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.

> Fundamentally, Apple don't recommend deploying applications like that. The
> users don't want to worry about installing and uninstalling applications in
> some new way so the libraries are shared. 

I agree that this is a drawback, but I consider it minor.

> The developers' lives are made 
> much easier when they only need to support a single version of Qt, D-Bus
> and KDELibs rather than this being updated when the user installs a new
> piece of software.

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.

> I know this is free software but looking at the way Linux does things and
> trying to apply it to Mac and Windows is the wrong way round. If you want
> to produce software that your users will want to use, you want to do things
> in the way they expect it to behave on that platform. This much is basic
> HCI and it's why Qt spends so much time trying to do the most sensible
> native behaviour on each platform.

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.).

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

> If we make it much harder to install Kontact than Thunderbird (which pretty
> much every proposal other than the CPack one does) then users will not use
> Kontact. This is why I don't use Kontact as my mail client at the moment
> and why many of the KDE on Mac people don't do so either: because it's a
> significant burden on the users to attempt to use it in Macports/Fink
> compared to native clients.

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.

Best Regards,
Bernhard

--

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner