[maemo-developers] Optification in MADDE, again

[From: Tomi Ollila]

On Fri 02 Jul 2010 14:28, Martin Storsjö <martin at martin.st> writes:

> On Fri, 2 Jul 2010, Tomi Ollila wrote:
>
>> 
>> There is a reason for that: Windows (below 7) (NTFS) filesystem does not
>> regognize symbolic links (properly); Generally, any software packakeable
>> with MADDE on linux should be also packaeable on Windows too...
>
> Yes, that's true, but even in that case, I think the deb packaging scripts 
> should support symlinks, if I'd happen to run MADDE on a system that 
> supports them. This is achieved with the patch I attached.
>
> This also makes the MADDE dpkg build system compatible with normal dpkg 
> build systems for packages that themselves create symlinks, but would of 
> course only work on MADDE on those platforms that support symlinks.
>
> What's the correct way of submitting this as a patch to 
> http://meego.gitorious.org/meego-developer-tools/madde? I attached it as 
> an git am'able patch here, too.

Well, partial solutions can be committed to anywhere but will not be
included in our MADDE releases. For consistency and support reasons we will
use the least common denominator principle (or whatever :) in the features

I've been thinking a solution where there is an 'ln' wrapper for windows,
which, instead of writing symlinks writes some kind of metafile which
describes it as a symlink... This has some risks, but just doing it during
installation phase (and just from a packager, maybe (triggered by env var))
could do the work. There is at least 3 options (+ combinations of these:

1) have a file 'symlinks' in directory. Maybe not good as rm:ing symlink
   would not work

2) make <filename>.symlink which contents describe symlink. same problem as
   above

2) make <filename> with magic content that describes that it is a symlink
   and what the symlink destination is. less problems than the above...

Then, dh_fixperms (and rrpmbuild.pl!) could know this magic and write
symbolic links to the packages accordingly.

In far future (2020) when we need not support symlinkless filesystems this
workaround can be removed (if written until that time ;)

>
> // Martin

Tomi