As I previously mentioned, and you acknowledged, not all extensions have a dep, so how would appbrowser check each file in a non-existent dep unless it tried to connect to a remote repository to verify such existence?
good point. i suppose you could switch from the if-no-dep-then-no-dep-file model to if-no-dep-then-zero-line-dep-file. if you think that's overkill, it may be.
That would mean TC is un-useable when not connected to the net whilst trying to load local an extension that needs no dependencies.
unless the "dep file" for a tce with no deps existed anyway.
What you are suggesting is to be able to start a process manually and expect appbrower to finish the job by CONNECTing to the net,
yes. the idea is that i started out not knowing what i was doing, then i learned that i should use appbrowser. only appbrowser is telling me the app is installed, but it isn't installed the way that appbrowser would install it for me if i hadn't improperly installed it the first time.
The INSTALL LOCAL does not ever expect to CONNECT, i.e., the verbiage LOAL LOCAL versus CONNECT.
i'm aware of the verbiage and i'm not suggesting anything that would contradict it. the only thing i would change is the behavior of INSTALL SELECTED, which relates exclusively to CONNECT. this implies internet access. load local would not be affected in any way by any of my suggestions.
the only change would be that INSTALL SELECTED (which always uses a net connection) would install all deps even if you "accidentally" installed some of them already.
by way of a manual process, means the extension could be stored at any location in the filesystem, which may not be recognized by the system upon reboot, i.e., a properly specified tce directory. And that compounds the issue.
this may be due to an misunderstanding not of how to use appbrowser, but how tce-fetch works based on guessing, so bear with me. as far as i know, my suggestion would not affect tce-load (thus it would not affect boottime loading) but only tce-fetch, right?
on boot, tc never tries to fetch packages. i wouldn't change that!
It is not the intended use of appbrowser.
well, i'm not saying that people *should* mix and match local and connect installs, only that if you botch a local install due to inexperience, appbrowser could (i only assume easily) clean up and download all the unloaded deps for a package.
Either the webpage needs much more instructions
i don't think that will help, it's about as clear as it can be and there will be people that misunderstand (or never read them, in which event it really doesn't matter how clear they are)
or the download link needs to be removed.
i hope it doesn't come to that, it's very convenient, i use it all the time to look up dep files. besides it also leads to the current and archive releases.
if you wanted to remove it, don't, remove the links to the tce and tcz folders in the "fancy" html of the downloads page at ibiblio, then for people to access the tce and tcz folders they will have to append the url with "tce" or "tcz." but i hope it doesn't come to that.
I think the best solution is to remove the readily able download link, rather than to propagate the unintended use of appbrowser and all that would imply.
depending on how complicated my "improvement" is, you may be right. the premise of my solution is that it would be trivial (in theory!) to modify appbrowser accordingly. if it's ultimately (in practice) not trivial, then i don't stand by my suggestion. if it ever became trivial, i would still be interested.
the intention behind the entire thing was actually to make "connect > install selected" a little more true to its label, (not less,) even in a situation where someone has tried to install manually and not managed it... ultimately so if someone's having trouble, it's much easier (for us) to help them. if this won't make it easier (for us) to help, then it's really not worth it.
Welcome
FAQ
Downloads
Wiki
