special environment / parameters for compiling tcz home-made?

[nick65go]

May I suggest you, that environment / parameters for compiling tcz home-made, to be always added into .info file of tcz? Or maybe as a readme.txt inside the tcz, as the size of this info is insignificant even without squash-ing it.

Please take example from arch linux way of making packages, it is just so simple, but documenting the process is like gold.
https://wiki.archlinux.org/index.php/Creating_Packages#Defining_PKGBUILD_variables

I have read the http://wiki.tinycorelinux.com/Creating+Extensions#Installing
But it seems it is not  a practice to document the process because of this statement : "It is not required, but certainly recommended, that you include any additional build instructions in a plain text file for future reference, mentioning such things as which extensions are required to build the package and what compile flags were used."

Plus, with a small script in tcz (or your /resource website), anyone could automatically recompile the software for another CPU (atom, core2duo, etc) and extend the goal of TC toolkit (as to not only assemble ready made tcz). I see not point to try & error, instead of walk on a known path highlighted by extension maker.
 
Thanks.

[tinypoodle]

The size of the info is most significant for more than one reason:

1. Browsing extensions, be it with a web browser, or ab/appbrowser.

2. The content of .info files should be read in whole by every end-user as well to decide about installing an extension, as well to make proper use of an extension. Adding info regarding build process which does not directly concern the end-user - many lacking either understanding or interest in such - would not benefit anyone, IMHO.

All the files relevant to compilation of extensions can be found here, freely accessible by whomever has an interest:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/tcz/src/

As you referenced an example of another distributor and I have to admit it is quite some time I last had a look at sources repos other than those of TC, I wondered if perhaps methods have changed recently.

A look at the sources repo of the most traditional of all major distributors convinces me that TC is doing the right thing.

For reference a completely randomly chosen example:
ftp://ftp.wh8.tu-dresden.de/pub/linux/distributions/slackware/slackware-current/source/xap/blackbox/

[nick65go]

thank you for pointing me in the right direction:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/tcz/src/

strange, my problem was that this branch is not visible in my browser if I start from this (parent) location:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/

of course, now I found also the link from
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/tcz_3x.html

sorry for noise.

PS: it all started from hdparm.tcz (which by the way is not in /src  ). because I want to restore max speed on my SDD, by issuing a SATA secure erase command (busybox hdparam has not this command). And I find that even with the hdparm 9.36 I must recompile the kernel as a parameter such CONFIG_TASK_IO_CTRL is not activated...

[tinypoodle]

sources of extensions which haven't been updated since a major earlier TC version can be found in the respective repo   

http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tcz/src/hdparm/

[nick65go]

this info is also really welcome, thanks again.

[tinypoodle]

Have you made sure first that hdparm is the right tool for your purpose - or perhaps sdparm would be more suitable?

http://sg.danny.cz/sg/sdparm.html#mozTocId752074

[nick65go]

i think my dell mini 910 has a PATA (UDMA 0-6, 16 GB SSD, STEC PCIe, http://www.stec-inc.com/product/umssd.php), not SATA, as dmesg says. So I will use info from here:
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

[tinypoodle]

May I suggest you, that environment / parameters for compiling tcz home-made, to be always added into .info file of tcz? Or maybe as a readme.txt inside the tcz, as the size of this info is insignificant even without squash-ing it.

Umm, I realized belatedly that I had misinterpreted part of upper.
All my statements in Reply # 1 were meant to refer to the .tcz.info file, and not to an additional  text file within an extension, which might indeed not take up much space when squashed.

However, the status quo is that neither the .info.tcz is included in an extension and also if any build info would be included it would need to have a very clearly distinguishable name, making it explicit that it is not addressed at every end-user as the suggested 'readme.txt' would imply.

[nick65go]

However, the status quo is that neither the .info.tcz is included in an extension and also if any build info would be included it would need to have a very clearly distinguishable name, making it explicit that it is not addressed at every end-user as the suggested 'readme.txt' would imply.

The status quo is not forever. So, my point of view is:
- any name & folder into .tcz is OK as long as ALL info in included inside.
- any .info & . dep & build instructions, and so on, COULD be in tcz

My scenario is that I use appbrowser to read the info before try the extension. But later, I have to unnecessarily fire again the browser and connect to the internet, read the info, and search for build instructions in various places, etc.

I wonder why this waste time procedure. Even if, let say, dep file are updated, or small info changed, IMHO it is worth to have an optional folder into tcz with old bits of info about extension creation (history).

The main info will remain in specific files as dep, info, etc. But text files inside tcz will not hurt tcz size. I saw some not necessary lang, sound, image etc into tcz, more bloat than my suggested text infos.

As a general goal, I think the scripting of extension creation is the future, and for others (without willing/ knowledge/ resources, just try for fun/ benchmark etc) tcz will be the fastest solution.

[tinypoodle]

The main info will remain in specific files as dep, info, etc. But text files inside tcz will not hurt tcz size. I saw some not necessary lang, sound, image etc into tcz, more bloat than my suggested text infos.

The difference being that those would probably be data files to be used in conjunction with the binaries.

Besides from leading to possible confusion if files related to the sources would be included into binary packages, there is the following disadvantage I could think of:

As TC mounts each extension on its own dedicated mount point, when looking for info I would often 'grep -ir keyword /path/to/mountpoint/of/extension'. I have come to appreciate this possibility as an advantage of the specific structure of TC. If there were files irrelevant to the usage of the binary included in extensions, then besides from grep'ing taking much longer, it could lead to a lot of "noise" in output.

[nick65go]

I still see no disadvantage, because:

1. size of tcz will not grow much, as txt files will compress very well.

2. noise (from grep) could be prevented by filtering/piping of grep input/output. Or maybe compress (lzma, bzip etc) the txt info in its '/resource' folder inside tcz just to don't have grep results.

3. time to search few txt files is insignificant (few seconds?) on any actual CPU. Even 100 grep commands will not feel the delay (manually or in scripts). Please do not worry about few seconds total delay when you spend at least half hour to debug/study a tcz.

The idea of build scripts and info for any extension into tcz, to document the maker steps, is to allow to study offline, no need to load again and again the same info, or hunt for tips or tricks in various places.

You see, for TC base we have wiki and FAQ. But for tcz, less centralized info. It is not about finding information, as Google and Wikipedia or Debian sources are our friends. It is just for a fast start to customize a TC for a specific laptop etc.

[curaga]

I read your main points as
- build scripts are not in a standard format
- they are not easily found

The second point should be easily changable. Where do you think we should add links?
Currently we have a link on both the top and bottom of the extensions html page:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/tcz_3x.html

I'm also against including any source material into the (binary) tcz packages. No other package manager does so AFAIK either.

[nick65go]

Hi curaga,

Thanks for replay. My suggestion:
- in http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/tcz_3x.html
could we have a new column (after info / dep / md5 / dep) as build instruction / script link?
-could appbrowser have a new tab to download build script, same as it shows info or dep tabs?

- you do not have to copy/ be like 'others package managers'. TC is your team distribution toolkit. if I am the only one that feel this info should be easy available/standard format to just compile it, then ignore my suggestion.

Regards.