Tiny Core Base > TCB Bugs

appbrowser not installing deps for packages -that are already- locally installed

<< < (2/3) > >>

tobiaus:
i know that not every tce has a dep... actually this problem would never occur for tce's that do not have a dep.

let me argue this is a small problem, although i think it's an easy thing to fix. but first let's clarify what the issue actually is, because i think i'm being misunderstood.

i could try to explain why i choose to list this a bug, that's not important now, but if i had only put it under "tcb talk" i might not have been misunderstood. i wasn't trying to mislead though, i was hoping i'd be understood the first attempt i made to explain.

in the interest of clarity, here are two scenarios. mine (labeled: "me") is typical of many new users, also. for users that have trouble with the instructions (bolding it further will help more if the reader's english is good...) the other scenario may prove relevant:


 

roberts:
A mountain out of a mole hill. If you started manually then finish the job manually.
Don't mix use of tools and expect full automation.

If this is a mountain, then the webpage needs to be removed.

tobiaus:
the problem with the alternative scenario is it feeds itself. someone who has trouble understanding the instructions (because english is a second language) will eventually figure out how to install the deps, but is likely to now think that installing apps in tc is very complicated (we know it isn't. he just made it so.)

i already agreed it is a mole-hill, i'm not trying to make a mountain out of it. rather i'm suggesting that instead of letting people make mountains of it in the future, it should be very easy to remove the mole ahead of time. an ounce of slightly tweaked design is worth a pound of explanations.

the solution i have in mind (and if it's not worth it, please don't use it) is... take leafpad for example. here is appbrowser's logic (forgive me if i'm wrong, you wrote it but i'm guessing how it thinks from using it)

reality: just leafpad.tce is installed, even though it needs:
expat2.tcel
glib2.tcel
graphics-libs-1.tcel
libxml2.tcel
fontconfig.tcel
ttf-bitstream-vera.tce
gtk2.tcel
atk.tcel
cairo.tcel
pango.tcel
pixman.tcel

1. i tell appbrowser to "install selected" leafpad.tce 
2. it checks only that item if it's installed
3. if it's not installed, it installs everything.

the solution: (the improvement on the original design)

1. i tell appbrowser to "install selected" leafpad.tce
2. it checks each item on the .dep list (which i think tc keeps now anyway?)
3. for each file listed in the dep, it installs them if they're not installed.

if implementing this is a terrible idea for some reason (very noticeable realtime ineffeciency) then i understand why no one changes it. if it was really difficult to do or hurt the simplicity of tc, i'd understand.

i think it's just a question of checking a few installed tce's instead of one. i don't want it to change the way tce's are loaded on boot- just when they're being downloaded from the net, via appbrowser.

then when someone thinks (incorrectly) he's installed every dep, he can make certain by using appbrowser. i think it could save a whole mountain of little molehills in the long run.

but if it's really not worth it, forget i said it, i won't mention it again i promise.

roberts:
The problem with your improvement is that it is specific to your example.

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? That would mean TC is un-useable when not connected to the net whilst trying to load local an extension that needs no dependencies.

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, i.e., not LOCAL, to do a verify and finish the downlaod/installation. The INSTALL LOCAL does not ever expect to CONNECT, i.e., the verbiage LOAL LOCAL versus CONNECT. Besides, 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.

It is not the intended use of appbrowser. The modes of appbrower is to stay local and load locally from a proper PPR or optional directory in the PPR or connect and download into a PPR or PPI as evidenced by the two menu options.

Either the webpage needs much more instructions on how to manually download all the pieces into a properly recognized "tce" directory or the download link needs to be removed.

Seeing as there is much work to manually download many pieces together with an understanding of where such extensions and related files need to be placed,  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.

tobiaus:

--- Quote from: roberts on April 09, 2009, 06:03:35 PM ---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?
--- End quote ---

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.


--- Quote ---That would mean TC is un-useable when not connected to the net whilst trying to load local an extension that needs no dependencies.
--- End quote ---

unless the "dep file" for a tce with no deps existed anyway.


--- Quote ---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,
--- End quote ---

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.


--- Quote ---The INSTALL LOCAL does not ever expect to CONNECT, i.e., the verbiage LOAL LOCAL versus CONNECT.
--- End quote ---

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.


--- Quote ---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.
--- End quote ---

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!


--- Quote ---It is not the intended use of appbrowser.
--- End quote ---

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.


--- Quote ---Either the webpage needs much more instructions
--- End quote ---

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)


--- Quote ---or the download link needs to be removed.
--- End quote ---

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.


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

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page