Re: [Fink-devel] .apps in fink

[mathias meyer]

max, ben, bill and all,

let me add my thoughts as well. what is actually the gain of having .apps in fink? for you it is none as you pointed out. the main reason why i'd like, and i might here speak for others as well, to have .apps in fink is the following:

software updates might bring great improvements, fix bugs that used to annoy me etc. therefore i'd like to get the new version quite quickly. but how do i stay informed about these updates? yes, in most cases there are mailing-lists etc., i know. good enough if these are only a few apps. but can you imagine keeping up to date with the all fink packages o your system without the automated update process? i mean, one could check the webpage daily and then manually download the new info files and install them manually, one at a time. would work. but a quick fink selfupdate-cvs, fink update all is much more convenient. this is a feature i'd love to have for my .apps as well.
(correct me here if i'm wrong: does versiontracker have some sort of a mechanism for announcing new app's? haven't much of a clue here, i admit. still i'd love to get these apps via fink...)

now there's the problem with moving apps around. the idea of symlinks might be a possible solution but i see problems there. some possible scenarios:

situation: you have an app (hidden directory) and a visible symlink to that.

update:
1) make a new symlink? (therefore must have the whole version including rev number in the name)
2) replace the old one? (but where is it...)

neither 1) or 2) are good solutions.
for 1)
usually there's a reason to have a new revision (not talking about versions, here you might want to keep an old one sometimes), you want to replace the old revision completely.
for 2)
well, one could search the old one, make sure it it the one from fink and then replace it. one could also have a symlink to a symlink (hidden) and only update the target of the second symlink to point to the new version, whereas the movable symlink still has the same target.

remove:
how would you remove packages? just leave the symlinks on the system? search for them?

these are just basic operation every user would do. it all leads to searching the system. therefore my proposal:

when a user wants to update/remove (perform basic operation) an app then:
1) look in the default place (/sw/Applications). if it's not there...
1b) search the system for the app. get get the new path.
1c) change /sw/var/lib/dpkg/info/*.list to the new path
2) perform the requested operation with dpkg.

in more detail:
- the first time the user wants to install an app: ask for the default place ([/sw/Applications] or anything the user wants) and store that path in the fink.conf in $apppath or similar.
- in every app that is installed i suggest one of these: a) put a file in *.app/Contents or b) modify *.app/Contents info.plist or *.app/Contents /version.plist to mark this app as installed with fink. this prevenst removing a manually installed app of the same version.
- fink scanpackage would search for all installed apps each time it is run. first it looks in $apppath from fink conf. if all apps are there, fine. if one is missing seach the system (first in /Applications, then in ~/Applications, then the whols system). as users usually stick to a few places: once the missing app is found, append the path leading to app in $apppath. in can be assumed that the user will place more apps there, ie the next time they will be found without searching the system.
- fink scanpackages would further modify all the /sw/var/lib/dpkg/info/*.list files if neccesary.

weak points:
1) dpkg (run through dselect or from console) could fail if the apps were moved in the meantime, as if doesn't first run fink scanpackages.
2) searching the system costs time, especially on a big drive.
3) i'm sure you find some more...

for 1)
personally i have anacron which is set to update my locate.database regularly. on the other time running anacron takes system recources.
for 2)
building the locate.database would help as well.
for 3)
these are just my suggestions. feel free to criticise them, add to them. or even like them :-)

mathias



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel