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

[Jannis Pohlmann]

Hi.

Benedikt Meurer schrieb:
> Jannis Pohlmann wrote:
> 
>>Hi all.
> 
> 
> Jannis,
> 
> 
>>Website:
>>http://installit.xfce.org (I'm just filling the Wiki with content)
> 
> 
> I have a few comments on whats currently visible on the wiki:
> 
> 
> 0. Name
> -------
> This is not really important, just a cosmetic question: How about using 
> "i2t" for directory/file names?
> 

Yeah, that would at least make them shorter. And perhaps the executable
could be called "i2t" as well, otherwise the user might be confused.

> 
> 1. Dependencies
> ---------------
> I think it's not a good idea to add python-glade2 and 
> installwatch/zengarden to the dependencies. Both are unnecessary and 
> make it harder to use the installer. You can design the GUI with Glade 
> and then quite easily transform that into Python code (if all fails, I 
> can do that for you). And concerning installwatch: This is not something 
> that is usually installed on the average system. You can do installation 
> tracking just like InstallIt does now, by first installing to a 
> temporary location, checking the files installed, and afterwards 
> installing to the final location. This works for all but the most broken 
> packages (which should be fixed anyways).

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.

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?

> 
> 
> 2. Paths
> --------
> Hardcoding /etc and /var for the local paths is not a good idea, as that 
> way you loose one of the best features of InstallIt: Local installation 
> without root priviliges (which - for example - Olivier and I used very 
> often to update certain machines at work, where we don't have root access).

I already thought about defining those paths in the config file. We can
do that, no problem.

Concerning the config file: My draft suggests /etc/installit/config.xml
but with making InstallIt available for the usual user we'd have to put
it in every user's home directory (fitting with freedesktop standards,
of course).

> 
> My attempt was to let the user choose a prefix under which everything is 
> installed (including the installer/uninstaller information itself). I 
> think this should be the way for the new InstallIt too. On first run, 
> ask the user to select a toplevel directory where all stuff gets 
> installed (you'll need some magic here to set sysconfdir to "/etc" in 
> case the user selects "/usr", and the like, but that's easy and you can 
> check the existing code to avoid trapping into the same wholes as I did :-).

Right, the prefix feature is important. I didn't mention it on the Wiki
yet but It's already been intended.

> 
> The selected prefix is saved in a special file in the users home 
> directory (e.g. $XDG_CONFIG_HOME/InstallIt/prefix). Then the initial 
> setup on the prefix is performed (e.g. mkdir "$prefix/etc/installit", 
> mkdir "$prefix/var/cache/installit", ...).
> 
> For unpacking and building, you should allow the user to specify a 
> custom directory, and before trying to unpack/build, calculate the 
> approx. space required for the building and check if enough space is 
> available on the selected directory (this was one of the most oftenly 
> reported problems with the previous installer).

If we make one directory customizable we can just go for them all. Hehe.
Every local path except the config file location is going to be
changeable by the user.

Calculating the approx. space is a good point, indeed.

> 
> One final note about the config file location: It may be a good idea to 
> allow the user to add overrides to a file 
> $XDG_CONFIG_HOME/InstallIt/config.xml, so he/she can easily saves it's 
> customizations and maintain it when upgrading InstallIt.

In my opinion, $XDG_CONFIG_HOME/i2t/config.xml (or ...InstallIt...)
already contains the user's customizations. But we can offer a backup
feature for it (and run it automatically if InstallIt is upgraded).

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

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

> 
> 
> greets,
> Benedikt
> 

Regards,
Jannis