[Inx] Thread three: Ideas

[Peter Garrett]

On Tue, 16 Sep 2008 06:50:17 +1000
"David Symons" <david.symons at liberatedcomputing.net> wrote:

> Hi Niels,
> 
> On Mon, Sep 15, 2008 at 5:18 PM, Niels Egberts <niels.egberts at gmail.com> wrote:
> > * An easy way to upgrade INX. I think the nicest method would be to create a
> > .deb file with all the inx-scripts and let it depend on anything that needs
> > to be installed on top of ubuntu-minimal, like vim, aptitude, pine, etc.
> > Then it should be fairly easy to set up an inx-repository so that anyone can
> > just use "sudo apt-get upgrade". For now, a PPA (personal package archive)
> > on launchpad can be used. Everyone can host up to 1GB in the repository. And
> > with that repository maybe it would be handy to be able to install INX on a
> > regular ubuntu installation. I've got a minimal knowledge of creating deb's
> > (I've packaged a few) but I would like to help in this process.

Originally, (when I started this madness last year) I had in mind to
make INX an "addition" to Ubuntu. The reasons why I did not continue on
this path were mainly about configuration, and in particular issues of
permissions on devices including the frame buffer,
(/dev/fb0) , /dev/input/mice, and /dev/tty0 etc., coupled with the
difficulty of making the tty/ vt with fb stuff work for a wide variety
of hardware, and so on.

If the frame buffer resolution is set in a way that is incompatible
with the X settings and settings for the Ubuntu boot-up, things become
complicated rather quickly. (I should probably say, too complicated for
my limited knowledge).

Without a frame buffer of course, INX is not really possible - or at
least, quite a few of the apps would not be possible.

Quite a lot of INX relies on settings in $HOME, which originate
in /etc/skel. There's a risk that some of this could clobber existing
configs, but that is probably something that can be avoided by checking
what already exists for the user. An alternative already suggested by
David would perhaps be a "dedicated" $HOME/.inx/ directory that would
contain inx-specific tweaks, but for example the mutt config might be
an issue, without some kind of wrapper...

> 
> https://wiki.ubuntu.com/PackagingGuide/Complete is a really good place
> to start.  As is the Debian New Maintainer's Guide
> (http://www.debian.org/doc/maint-guide/).
> 
> Currently INX's files are installed in the /usr/local directory tree.
> That will have to change in order for INX to be acceptable to
> Debian/Ubuntu (which I feel it should aspire to be).

I used this tree in a way as a symbolic means to emphasise that  INX
is an "add-on" to Ubuntu. That of course does not mean it can't be
changed...  

> A possible restructuring would be to :
>     - just have the one 'public' executable: /usr/bin/inx
>     - the rest of /usr/local/bin moved to /usr/lib/inx/bin (except
> bits that can logically be packaged separately, eg. cdmp and plait
> (*g*).
>     - things within /usr/local/share moved to /usr/share

That looks like a good way to do it, agreed.

> 
> That said, another upgrade method could be to distribute INX with
> links to a Bazaar branch (on Launchpad).  Then an update could be
> simply:
>     cd /usr/local; bzr pull

Clever idea :) If that approach is to be used though, more files would
need to be placed in that branch so that system file updates
(/etc/skel, additions or changes to example files etc) would be
included. Alternatively, instead of using /etc/skel INX could simply
plonk a lot of the config in something like /etc/inx/ , I suppose.

> 
> > * Adding support for gettext to the scripts. For the ones that don't know,
> > with gettext you can easily make your program multi-lingual. When you print
> > a string, gettext searches for that string in the various .mo-files (1 file
> > for every language) and prints it in the language chosen by the user. Also
> > it can be linked with https://translations.launchpad.net/inx so that
> > everyone can easlily help with translations whithout knowing about the
> > technical stuff. I think being able to learn to commandline in your own
> > language can be a big help.
> 
> Great idea!  The challenge will be translation that preserves the
> wonderful "Peter_Garrett-ness" of the introduction, tutorials etc.
> :-)

Not everyone would agree with your assessment of my intro and tuts, but
thanks anyway ;) 

Currently, INX installs "localepurge" and pretends that
the world speaks English. This piece of blatant cultural imperialism
has mostly to do with keeping the ISO size fairly small, and panic
attacks when contemplating the difficulty of maintaining a
multilingual distribution :)

Peter

-- 
"INX Is Not X" Live CD based on Ubuntu 8.04 : http://inx.maincontent.net
Screenshots slideshow: http://inx.maincontent.net/album/1.png.html