[Installit-dev] "package manager " becomes "InstallIt"

[Benedikt Meurer]

Jannis Pohlmann wrote:
> Concerning Glade: Ok, I'll have a look into the ways of transforming
> Glade into Python code. The major disadvantage I see here is that each
> class connected to a GUI will grow lots larger. But we'll see.

You can keep that in a single method init_gui() for each class, that'll 
help to keep it in one place. It's better to have more code in this 
case, so we can hopefully reach the "out-of-the-box"-goal one day.

> Concerning zengarden/installwatch: I wrote a tiny package management
> tool some weeks ago and tried it the way you did. Well, it's ok but I'd
> prefer to use something like zengarden. I don't know the packages
> zengarden depends on but if it's just standard C library or something
> like this perhaps shipping a precompiled version of zengarden within the
> InstallIt distribution could work?

A precompiled version for N different systems? That is unlikely to work. 
You could probably compile it on demand (if it is portable), but then 
you depend on atleast the compiler and the dev packages for the system 
stuff, which goes against the "out-of-the-box" attempt with binary 
package installation.

>>3. Single Instance
>>------------------
>>Again, "/var/lock" should not be hardcoded. And one word of warning 
>>concerning file locking: Locking can lead to very tricky problems with 
>>NFS if not configured properly. We had a problem with libxfce4mcs and 
>>locking on NFS already, that was very nasty. In case of the installer 
>>precise locking is not required. I'd suggest to just use a file 
>>"$prefix/var/lock/installit.pid", where a running instance stores it PID 
>>to, and when starting a new instance, you simply read that file, and try 
>>to kill($PID, 0) it. If the answer is positive, refuse to start. If 
>>something goes wrong, the user can simply delete the lock file and 
>>everything will be ok. You save a lot of trouble this way.
> 
> http://installit.gezeiten.org:2500/installit/show/EineInstanz
> ("Unsichere Methode") - I already prepared a solution for that. We can
> use this if you prefer it. For me, both are fine as they just work.

Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's 
really not worth the trouble with fcntl()/lockf() locking. And we're not 
developing a critical database, so if a user manages to start two 
instances of InstallIt, then he'll run into trouble and may remember to 
read the documentation when he uses a software next time. ;-)

>>4. Mirror List
>>--------------
>>It would be nice to have a name/description to each mirror. In addition 
>>it might be a good idea to add the country in which the mirror is 
>>located, so users can choose a mirror close to them.
> 
> We thought about name and description, too. To be honest, we considered
> it a waste of time. The domain ending (.de, .co.uk etc.) already may
> give a hint whether a mirror is close to the user or not.
> Personally, I prefer the puristic solution: Just choose between URLs.
> But since we're attempting to satisfy even less advanced users we can
> add information, of course.

Unfortunately domain endings are pretty useless these days. I'd prefer 
to have atleast a name/description and the country attached to the 
mirrors. And the GUI should sort the mirrors by country, e.g.:

* Germany
  - Bla
  - Blub
* Netherlands
  - Narf
  - Foo
...

Preselecting the last used mirror (or the closest mirror on first run, 
e.g. the first mirror for the country of the user). The less user 
interaction you need, the better (but still provide the possibility to 
change things if the user wants to).

> Regards,
> Jannis

Benedikt