[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