[mhvlug] distro packaging considerations [was: Switching back to Chrome from Firefox]

Ron Guerin ron at vnetworx.net
Sat Aug 28 22:05:29 EDT 2010

Chris Knadle wrote:
> On Saturday 28 August 2010 19:30:45 Ron Guerin wrote:
>> Chris Knadle wrote:
> ...
>>> My girlfriend Criss uses this URL shortener, which she seems happy with.
>>> It's in PHP and uses MySQL for the DB backend.
>>>    http://yourls.org/
>>> At the moment I don't think there's any URL shortener within Debian
>>> AFAIK.
>> I'm trying to re-write mine to be less horrible code and to take into
>> account some reasonable feature requests I've gotten, like translation
>> files.  I'd be honored if it somehow got into Debian after that,
>> although I thought they had higher standards than anything I produce.
> As far as I know (disclaimer: I *do not* have direct experience in this area), 
> there are basically three things to consider when trying to get a project 
> uploaded to distributions:
>   A) marking a particular version of the software as "stable" [important]
>   B) software code portability for other architectures
>   C) support for localization [i.e. l10n written language translation]
> A) is most important, as Debian packagers typically will only package software 
> versions that are marked as "stable".  This is the part that can annoy 
> software authors, as it means what is packaged might be somewhat old.  From 
> the package management point of view, the packager wants to know that the 
> software has been tested and works, i.e. "stable".  After the software is 
> packaged it is then first uploaded to Debian Sid, also known as "Debian 
> Unstable".  So ironically this generally means that only "stable" software 
> gets uploaded to "Unstable".

This may be an issue.  The code I run and distribute now has been marked 
"alpha" for about six years now. lol  I'm primarily though maintaining 
this branch of what is production code and hoping to move forward with a 
cleaner, faster re-writing. ([*] I know Joel says this is bad, but I 
doubt Joel was thinking about hack hobbyists)

> B) can be important as distributions support many architectures -- and it 
> would be nice if the software produced would, say, work on an ARM-based laptop 
> or mobile device.  In practice what happens is an auto-builder daemon is used 
> on the software package, and if the package fails to build for a particular 
> architecture then the software simply isn't made available for that 
> architecture.

I am fortunate in this regard to be distributing 
architecture-independent code.

> C) is important because distributions support a lot of written languages.  
> UTF-8 unicode support is important too, as it's the default LOCALE upon 
> installation at least for Debian.  A friend of mine using a Mac recently had 
> trouble with this concerning the 'tr' command to translate carriage-returns to 
> line-feed characters.  He did the following, which was very logical and should 
> have worked:
>    $ cat funky_lines.csv | tr '\r' '\n' > fixed_lines.csv
> However the file he was modifying contained UTF-8 characters, and the 'ö' 
> characters [that's an 'o' with two dots above it] cause the 'tr' command on OS 
> X to die with an error of 'illegal character' because it apparently isn't 
> UTF-8 aware.  Oops.  [The 'tr' command on Debian /is/ UTF-8 aware, BTW.]

My recollection is PHP is not particularly good at handling UTF-8.  But 
that said, all other PHP scripts in Debian will have the same 
limitations I do.

> Obviously you cannot do the written language translation yourself to all of 
> the languages that a distribution might support -- it's just important to put 
> in /support/ for translations so that someone else can translate the strings.

Several of my users (I mean the people who install my code), have 
requested translation support and offered translations, and it's the 
most requested thing after the API, so I'm planning on supporting 
translations at least.

> I've dealt with translations in Qt using the 'tr' macro wrapper around 
> strings, but I'm not sure how localization is typically handled in, say, 
> C/C++, bash, Python, etc in an architecture-generic way.

This is how I'm handling it:


     echo _("Hello World!");

This looks up the localized text for "Hello World!" in the translation 
file and echos the translated text.


I realize you probably have no interest in the PHP bits of this, but I'm 
putting it all here in case it's of some use to someone else.  When I 
first looked into this, it was not at all clear to me how exactly a GPL 
program ought to do this in PHP.

- Ron

More information about the mhvlug mailing list