Windows-Packaging

[Bernhard Reiter]

Hi Ralf,

On Mittwoch, 14. Januar 2009, Ralf Habacker wrote:
> > My experience with the discussion is, that it is difficult and we need to
> > inquire more. This prevents an effective meeting as of today, because it
> > is hard to decide in a low data situation.

> you mean a low experience situation ?

however you call it, we are lacking enough information for some point.
Some things we could only know after trying as there are no experiences
with this yet. ;)

> >> In the past we got several requests/ideas from which the
> >> following topics are extracted:
> >>
> >>     - package size improvements (better compression e.g. lzma)
> >>     - single application packages
> >>     - dependency improvements and base package splits to reduze required
> >> installation size (there were reports that amarok needs about 500 MB
> >> installation size yet)
> >>     - single application standalone installer
> >>     - required installer features and improvements
> >>     - more topics ?
> >>    
> >
> > One discussion on gpg4win-devel@ went into the subject, start
> > the thread with  the last part of the following email
> > http://lists.wald.intevation.org/pipermail/gpg4win-devel/2008-October/000
> >760.html 
>
> I see -
>
> autobuilder - are you refering to
> http://www.debian.org/devel/buildd/index.de.html ?

You probably refer to
On Dienstag, 30. September 2008, Marcus Brinkmann wrote:
| We can do this in addition to daily autobuilds.

Our aim is to have an automated build system rebuild the binaries as soon as 
possible when there is a new version. The Debian system does this on uploads
and some other rules as far as I know.
For some of our Debian Package we run http://saegewerk.intevation.org/
based on http://treepkg.wald.intevation.org/ software which uses Debian's 
pbuilder, but not the buildd.

> hmmh, I had no time to go through the whole thread - but I stumpled over
> the following sentence
>
> > It would also be good if kleopatra would get rid of the little issues
> > like not following the expected packaging and
> > needing a bin directory.  
>
> Why is it bad to have a bin directory 

Unfortunately the discussion is touching several topic including longer 
discussions within Gpg4win. This is one of the issues that revolved 
with libraries paths, specific application needs that history limitations.
In short, this is a different topic. :)

> The recent kde distribution is build up to need as little as much efforts
> for packaging - why should there on windows two different path layouts -
> one in the main distribution and one in the msi or nsis installers  ? 

In principle there should not be two layouts. I cannot recall without 
rereading myself what the history reasons for the current layout is.

> >Currently we (as in KK team) attack the dbus on windows problem.
> >Also we try to get experience with cross-compiling kdepim (and the stack
> > under it) for gpg4win. Cross-compilation is interesting to solve several
> > problems with builds and distribution for KDE on windows.
> >
> >- We need to ship the exact source code, scripts and tools to build each
> >  specific binary shipped for GNU (L)GPL licensing.
>
> As far as i know does the gpl licensing means only to provide the source
> for a related binary, but it does not make the binary releaser
> responsible to provide  all required 3rdparty tools.
>
> Think about msvc builds  -  We build kde software on windows with msvc
> express editions, but we don't provide the ide or the platform sdk - in
> fact ms probably will do not like this

You happen to ask a licensing expert about. In short terms the license
does require to deliver source for tools and libraries, except when they
are generally shipped with the operating system. (See below.)
But we also want to make it fairly easy for people 
to rebuild the exact version they are using, so they can only change
a small thing if they like.

> > Thus the packaging tool would need to assemble the source code.

> Not sure what you mean here.

The building and packaging process must directly fetch and secure
the source code that is needed for later distribution.

> > - We need dependency handling for the source code packages.
> >
> > Emerge currently cannot do this, Debian or RPM would allow this.

> I don't understand why the windows emerge should not be able to do the job.

Currently emerge does not fetch nor secure the source for all of the binaries
used for a regular build. Of course you could enhance it to do so, but this 
would be a major effort. (Just recently two senior Free Software developers 
reminded me within other projects that RPM, DEB and .msi are very compley 
software that took years to evolve.)

Bernhard 
-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20090116/08bb44d4/attachment.sig