Proposal for upgrading .tcz on .tcz.dep changed

[jazzbiker]

Here is the (hopefully) final version and time to relax

Something of that kind, I guess ;-)

By the way, isn't using GNU diff a shooting crows with the nuke? Haven't You tried

Code: [Select]

[ "$(cat file1)" == "${cat file2}" ]
?

[GNUser]

Hi jazzbiker. I agree that GNU diff is shooting a crow with a nuke here. cat is a good idea, but doesn't work by itself doesn't work because it preserves whitespace. echo eats whitespace, so if we combine cat and echo then it works

Also, I did some experiments and noticed that fetchmissing is not needed. If a new .dep file creates the need to fetch an additional dependency, the tce-update at the end takes care of it (tce-update has a "Fetching required dependency..." step).

So here is latest version:
1. Uses cat+echo instead of GNU diff for the comparison
2. fetchmissing is eliminated because tce-update already takes care of that

Your thoughts?

EDIT: If local .dep file differs from repo's .dep file only by order in which dependencies are listed, the update-everything script will still see the difference and will update the .dep file. This is desirable because sometimes the order in which the dependencies are loaded is important.

[jazzbiker]

cat is a good idea, but doesn't work by itself doesn't work because it preserves whitespace. echo eats whitespace, so if we combine cat and echo then it works

Damn! Shell is the best example how the road to hell is paved with the good intentions :-( You with Rich can ban me, but in my opinion loving shell is the kind of perversion ... Sorry for dumb complaining.

[jazzbiker]

Hi GNUser,

I can confirm that upon my personal tce14/optional in its actual state Rich's version and Your current version of update-everything work in the same way. But I gave up predicting in what kind shell will push us into the back in another circumstances/repo state. Maybe even GNU nuke is the final solution.

I can not agree about excluding fetchmissing. tce-audit fetchmissing uses recursive tce-load, while check_dependencies() in original tce-update provides fetching of the only one level of dependencies.

[GNUser]

I can not agree about excluding fetchmissing. tce-audit fetchmissing uses recursive tce-load, while check_dependencies() in original tce-update provides fetching of the only one level of dependencies.

Nice catch, jazzbiker. I put tce-audit fetchmissing back in.

I did some tests and, if a .dep file has been updated and now includes a new dependency, tce-audit fetchmissing does nothing whatsoever unless you re-run tce-audit builddb after the .dep file has been fixed. Tricky, tricky. Script now takes care of this.

Latest version of script (5.0) is attached.

[GNUser]

in my opinion loving shell is the kind of perversion ... Sorry for dumb complaining.

The shell sure does have a lot of warts and whiskers, can't argue with you there. But I love it, anyway. I'm okay with being strange

[jazzbiker]

The shell sure does have a lot of warts and whiskers, can't argue with you there. But I love it, anyway.

I know some people love gambling ;-) Well, not a single word more about my inability to understand everything in this world.

update.sh:

Code: [Select]

real    0m 45.41s
user    0m 8.70s
sys     0m 14.94s

update-everything:

Code: [Select]

real    0m 13.56s
user    0m 5.40s
sys     0m 6.05s

The gain is significant. 5.0 is nice number for the final version!

[GNUser]

jazzbiker, thank you for your collaboration. The script is that much better for it.

But I gave up predicting in what kind shell will push us into the back in another circumstances/repo state. Maybe even GNU nuke is the final solution.

No need for nukes. As long as the shell is Busybox ash and we are using Busybox utilities, script's behavior will be predictable. This part:

Code: [Select]

. /etc/init.d/tc-functions
useBusyboxtakes care of the latter (ensuring Busybox utilities). Since, technically, /bin/sh can be a link pointing to any shell whatsoever, we should probably change the shebang from /bin/sh to /bin/ash (to ensure the script runs in Busybox ash, which is the shell you and I have used to test the script).

I attach the script (again) with more specific shebang. I made no other changes.

Happy hacking!

[Rich]

Hi GNUser
The  rebuildfstab  script uses:

Code: [Select]

#!/bin/busybox ashThis way it doesn't matter where the busybox link is located or if it even exists.

It also includes this:

Code: [Select]

useBusybox

PATH="/bin:/sbin:/usr/bin:/usr/sbin"
export PATHuseBusybox  only includes some of the busybox commands, cut and ps are 2 of the commands that are missing.
The  PATH  setting pretty much forces all busybox commands to be used.

[GNUser]

Hi Rich. Thanks for the better shebang. Restricting the environment further by specifying PATH is a great idea. Version bump to 5.1.

jazzbiker will appreciate the added safeguards. Not all surprises are good surprises.

[GNUser]

One last thought: No need to build package database twice. It can be done only once, after syncing .dep files and before tce-update fetchmissing.

I'm going to stop attaching latest version of the script. This link will always point to latest version:
http://gnuser.ddns.net/public/update-everything

P.S. Rich, please feel free to delete all my attachments from this thread if you think it would reduce clutter and save space on the forum server.

[Rich]

Hi GNUser

... P.S. Rich, please feel free to delete all my attachments from this thread if you think it would reduce clutter and save space on the forum server.

Thanks, the number of attachments does need to be trimmed down again.

[GNUser]

Hi Rich. I have a question about this:

It also includes this:

Code: [Select]

useBusybox

PATH="/bin:/sbin:/usr/bin:/usr/sbin"
export PATHuseBusybox  only includes some of the busybox commands, cut and ps are 2 of the commands that are missing.
The  PATH  setting pretty much forces all busybox commands to be used.

It seems redundant to call useBusybox and also set this limited PATH that basically only allows busybox and base system commands. On a TCL system, the latter (limited PATH) accomplishes everything the former (useBusybox) does, and then some.

Can you think of any reason why a script such as rebuildfstab or update-everything should call useBusybox and set the PATH?

[jazzbiker]

Hi Rich,

Posts #8 - #12 may be easily removed along with the attachments.

[Rich]

Hi GNUser

... Can you think of any reason why a script such as rebuildfstab or update-everything should call useBusybox and set the PATH?

No, I can't. All I can tell you is  rebuildfstab  had both at least as far back as TC4.
It's possible  PATH  was added out of frustration to quickly force all busybox functions as defaults.