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

Jannis Pohlmann info at sten-net.de
Wed Aug 24 14:21:18 CEST 2005


Benedikt Meurer schrieb:
> 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.

That's fine. Any tutorials/documentation on this in the web that you
know of?

> 
> 
>>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.

Okay, zengarden/installwatch is dropped.

> 
>>>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. ;-)

Okay, I'll try using kill($PID, 0). I already thought about the fact
that /proc might depend on the distribution of the user so this sounds
like a smarter solution.

> 
> 
>>>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
> ...

Yeah. I just updated the Wiki:
http://installit.xfce.org/trac.cgi/wiki/MirrorList

> 
> 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).

Good idea, I'm going to keep that in mind.

> Benedikt

- Jannis



More information about the Installit-dev mailing list