Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: 4-stroke on October 19, 2009, 11:47:45 PM
-
Bashburn has coreutils.tcz as a dependency but such a thing doesn't exist. It's coreutils.tczl. ;D
-
Thanks - updated.
I'm not sure whether:
/usr/local/lib/coreutils/libstdbuf.so
..merits the "l", but anyway...
-
Technically, only a .so library that exists in the systems library path (/usr/lib,/usr/local/lib) would need the "l" suffix. But obviously no harm is done if the "l" is used when it does not have to be.
Thanks for fixing the dep file.
-
Technically, only a .so library that exists in the systems library path (/usr/lib,/usr/local/lib) would need the "l" suffix. But obviously no harm is done if the "l" is used when it does not have to be.
Thanks for fixing the dep file.
Interesting. Are you saying that all tcz's could be renamed tczl with no harm done?
-
With an "l" suffix, ldconfig is run during extension loading. Just like depmod is run when there is an "m" suffix. No harm to the system is done, but you want to run either only when you have to under normal circumstances.
-
With an "l" suffix, ldconfig is run during extension loading. Just like depmod is run when there is an "m" suffix. No harm to the system is done, but you want to run either only when you have to under normal circumstances.
Thanks for the explanation. It would seem that the effort to reduce the extension system down to one type of extension could go a little further and include the "l" and "m" modifiers as flags in the tcz file. This would also open up a path to add more flags in the future for various new options.
-
Not to make too fine a point of it, but I was told it was no-exceptions policy bash scripts were not accepted in the repo (for some reason).
What's bashburn doing there then?
-
I pulled my own scripted utilities when this decision was made and started using the scripting section of the forum, though as a developer I didn't have to. I am the type that is willing to live by whatever rules I enforce, and to lead by example.
We have many loyal and consistent contributors here who give me no problem abiding by the rules, and who don't feel they are above using the programming and scripting section of the forum.
Bashburn is easy to script a fetch and install with a few minor sedits, and I love to script. I have thus far made no exceptions for myself, it will go in the programming and scripting section of the forum.
-
Thanks for the explanation.
-
I didn't mean to sound so defensive, this is obviously not my favorite topic. You have a valid question as to why bashburn could be in the repo when there is a no scripts rule. As the extension person I plan on living by the same rules as the community when it comes to exetnsions.
-
No problem. On reflection, it's probably a good rule.
-
IMHO. The rule is valid for custom scripts. The intent was not to increase the work load on Jason by trying to validate such scripts. But for well known, throughtout the Linux community, a script like Bashburn, well, "methinks doth protest too much". I will however respect Jason's decision.
-
Robert, I was going to bring this up again as the "no scripts" rule as I have defined it, being a knee jerk reaction on my part, went well beyond the intended rule on custom scripting. I am known to take something and just run with it past the point of sanity.
As most python apps are simply a collection of scripts, same with bashburn, it is ridiculous to deny such just because they fall under the category of scripts. So here is what I think is the spirit of the original plan.
Scripts that are a custom version of tce-load, uninstallers/upgraders, icon/menu manipulation tools, those belong in programming and scripting. Submitting such will result in a recommendation to post in programming and scripting.
Scripts like python apps, bashburn, Edna music server, and such are perfectly ok in the repo.
I personally don't mind fetch and install scripts, if they are done with care, have been tested, and they "just work". There are examples in the scripting section. For those who are not well experienced in them, honing them in programming and scripting would be most beneficial. They should run as unpriviledged user, do all their work in a temporary directory in /tmp, and output their extension to the tce directory. In other words, they do not mess with any other part of the filesystem. I don't like to see a fetch and install script write to /home where data resides. There are not many fetch and install scripts, most are mine, and I can easily spot if one is doing something it shouldn't.
So in a nutshell, known scripted apps are acceptable. Custom utilities belong in programming and scripting. Mature fetch/install scripts can go in the repo, as I can easily spot if they are sane.
-
Glad to hear that the community will continue to have easy access to well known Linux programs that happen to be in script forrm.
-
It was simply a misunderstanding on my part. I am also glad now.