X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
Subject:	Re: Non DOS-friendly file names in DJGPP packages (binary and
	documentation only)
To:	djgpp AT delorie DOT com
References:	<55F53293 DOT 605 AT iki DOT fi> <55F5B34E DOT 1080206 AT gmx DOT de>
From:	"Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID:	<55F5D2FD.10502@iki.fi>
Date:	Sun, 13 Sep 2015 22:48:13 +0300
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.2.0
MIME-Version:	1.0
In-Reply-To:	<55F5B34E.1080206@gmx.de>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 09/13/2015 08:33 PM, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp AT delorie DOT com] wrote:
> Am 13.09.2015 10:23, schrieb Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]:
>> Today I posted about such directory names in gettext and libiconv packages.
>> This is however more widely spread problem. Wrote a simple script for performing
>> a check (script silently skips source packages)
>>
>> 'unzip -t' together with sed and awk is used to generate file list as doschk do not
>> catch incompatible directory names unless they are explicitly found in input
>> (they are not present in manifest files I have created)
>>
>> I attaching also results of running this script on djgpp/beta directory of my local mirror
>> (compressed with XZ as file was rather large)
>>
>> About source packages: I skipped them as for many of them we explicitly say that LFN
>> support is required.
>>
>> Andris
>>
>
> I have inspected the list and I do not think that there are really serious issues.
> The issue should only be considered serious if it inhibits the use of the port
> on plain DOS.
>
> As far as I have seen there are 5 types of issues:
> 1) Old ports that may have some SFN issues.  They will go into /deleted anyway
>    and I do not have the time to fix this and I do not think that it is worth
>    to be done.
> 2) There are binary ports with directory names that are not SFN clean like:
>      gnu/findutils-4.2.33
>    This is a pitty but I do not think that it is worth to be fixed because the
>    content of the directory is extracted anyway and the user can access to
>    those files.  This issue can be fixed in a next port.
> 3) There are binary ports with directory names that contain ilicit characters
>    for plain DOS like:
>      gnu/gettext-0.19.1/gettext-tools/examples/hello-c++-kde
>    This also not an issue because djtar or unzip will rename them during the
>    extracting process.
> 4) There are binary ports that contain files that have no unique SFN like:
>      share/doc/xz/examples_old/xz_pipe_comp.c
>      share/doc/xz/examples_old/xz_pipe_decomp.c
>    This is typicaly the case when the install target also installs some sample
>    under /share/foobar-1.2.3.  Of course, "foobar-1.2.3" stands only as an
>    example for some port.  In the next port version I will modify the install
>    target so that kind of files becomes no longer a part of the binary archive.
>    If some one installs on plain DOS he usualy has reduced ressources and there
>    is no reason to clobber the DJGPP installation tree with such package specific
>    sample code that has no real relation to DJGPP.  This will make the binary
>    archives smaller too and if the user is really interested in that sample code
>    he can install the source package in some temporary directory.
> 5) OpenSSL is a special case.  I have clearly explained in every announcement of
>    port that the man pange directory is not SFN clean.  There is a very large
>    number of man pages that would need to be renamed into some kind of DOS specific
>    fantasy name.  This would be a tedious job that had to be done for every port.
>    For every port I would have to inspect if names have changed or files removed
>    or added only to keep this renaming list up-to-date.  This effort is not worth
>    to be done.  Every user that reads the announcement is aware that he must
>    install the port with LFN enabled by some LFN driver.  After that he can
>    disable LFN again.  Anyway the port itself is SFN clean and is full operational
>    no matter if certain man pages have been installed or not.
>
> It should be completely clear that source archives always require LFN support.  To
> configure and build some port LFN support is always required.  I will not waiste my
> time fixing things like that.  In other words, the time of short file names has
> long gone.
>
I have no objections about source packages as we have given up to get build work on non-LFN systems.
That was reason why my scripts skips them without checking.

About directory names in binary packages:
for example for gcc-4:X:Y I face done something like

version=4.X.Y
djver1=$(echo $version) | sed -e 's:\.::2g')
djver2=$(echo $version) | sed -e 's:\.::g')

in scripts related to building DJGPP packages (I'm lazy enough to prefer to use scripts instead of 
creating packages manually).
After that it is question of using correct variable in each context in script to get files in LFN 
friendly way (at least to avoid
gnu/foo-X.Y.Z  by replacing it with gnu/foo-X.YZ). Removing second dot from version number is also 
not too nice when one of
parts gets larger that 9. Unfortunately there there is not too much what we can do.

I'm trying to keep binary packages I release non-LFN friendly. That is the reason why recent GCC 
binary packages do
not appear in the list (gcc-4.6.X is already rather old). I have not however succeeded always: 
gmp600b.zip is an evidence for that.

Andris

- Raw text -