Dynamic files in /opt

[gerald_clark]

Why not move all the dynamic files like .appbrowser, .backup_device, .tce_dir, and tcemirror to /etc/sysconfig?
That would simplify .filetool.lst.

[roberts]

/etc/sysconfig is not user writable. I suppose some could actually be moved to /tmp
I have mapped this out and it is quite substantial. It is one of those areas that is the effort worth the result.
I will consider.

[Rich]

Hi roberts
Depending on the number of files involved, maybe just add them to  .xfiletool.lst. Moving the files
means not only you modifying countless scripts, but might also break other peoples scripts. I
don't know if any applications rely on any of these files, but if they do, there will be breakage
there too.

[hiro]

I agree it's worth it because of consistency.

In my view we have too many names, there are too many tinycore specific files in too many different places.
/usr/local/tce.installed and /usr/local/tce.icons
TCE_DIR/tce/optional and TCE_DIR/tce/ondemand
/tmp/tce/
/tmp/tceloop/
/tmp/backup_xxx
/tmp/abxxx
/opt/.xxx
/opt/xxx
/etc/sysconfig
there's probably other stuff in initrd I forgot.

I agree changing stuff sucks, but if you could combine this change with other restructuring and push it all out together it should be ok. For user scripts: We all know how to use sed.

I once lost some files (and I'm still angry about this) because I did echo /opt/bla >> /opt/filetool.lst instead of .filetool.lst

[roberts]

If indeed you all know how to use sed then learning how tar works should resolve the questions regarding backup/restore.
BTW, most of the files that are listed are transparent to the user and are not included in the backup. Apparently this topic has surfaced only because of the lack understanding of documentation already provided and specifically the Linux tar command.

[gerald_clark]

Actually, I brought it up "because of the lack understanding of documentation already provided" by another user who has "opt" in his .filetool.lst, and
is hard to educate.

In some of my projects, I put all my config files in subdirectories under /opt. I don't like them scattered all over the place, and most services allow you to specify the config file at invocation.

I think I will take Rich's advice and add the few files in /opt that I don't want backed up to .xfiletool.lst.

[hiro]

Roberts, did you read the subject? It seems to me you're mixing up threads and persons.

[roberts]

My post was not directed at Gerald, but in general.  As I see this original post as a result from some other user trying to add "#" comments to a file list that is not supported by the Unix tar command. It was verified that this original post was indeed a result of the persistency fails post (  http://forum.tinycorelinux.net/index.php/topic,11721.0.html )

Should the case of a single user not knowing, or reading, how to do the basics, "hard to educate" result in a massive change of files. Breaking some 30 base programs and scripts plus who knows how many custom programs in the respository as well as scripts posted in the forum and wiki?

Should this distro be in a constant state of flux? Should all prior documentation be also revisited to reflect such changes? Should things be "fixed" that are not broken?

Sure I can effect these changes, but is the effort worth the result?

[gerald_clark]

I was just asking for opinions about the value of making the change, as I had been asked in the past to not write a config file to /opt, but to /etc/sysconfig.
I have seen other people put "opt" in .filetool.lst, so it is not an isolated case.
If the value of moving these files is outweighed by work needed to do so, that is all I wanted to know.

I see that there are files that are written into /opt that appear in neither .filetool.lst nor .xfiletool.lst.
Could this be a probllem if "opt" is listed in .filetool.lst?  If so, should they be added to .xfiletool.lst as Rich suggested?

I'm trying to see if there are ways to reduce the types of errors a user can make.  That would reduce the support workload.

[roberts]

Re: Cleaning up /opt dynamic system files and other planned changes coming in 4.2.
I have moved .backup_device to sysconfig in v4.1

I am planning to move .tce_dir for 4.2. This will be a big change!
Also not mentioned and rarely used, for initrd use only, /opt/tce will be moved and renamed. Details to follow.

Hopefully the changes will make for easier support.
I do appreciate the support that is offered in the forums!

I have been trying to improve microcore and free any entanglements with tinycore and where possible make tinycore truly a by-product of microcore + standard extensions = tinycore. Thereby promoting microcore as the core of our project.

[roberts]

Big changes are coming. Implementing this request has given me the opportunity to refocus the project based on its maturity with the goal of  improving core and freeing any entanglements with tinycore.  Where possible make tinycore truly a by-product of core + standard extensions = tinycore.  I have also completely revamped multicore with a completely new offering still with support extensions but many new choices. 4.2 is coming.

[hiro]

Yeah, feels like Christmas already
Happy developing.

[ThinClient]

New to Tinycore (love it) and to Linux (ditto) so this may be obvious to those who are steeped in the Ways of the Penguin:

1) Is there any movement (broadly) to consolidate the use/definition of particular subdirectories for specific purposes? And if so, what group(s) are so involved, any refs or URLs to their ongoing work?

2) Any "Elements of Style" or "Best Practices" type of white papers worth reading relating to organization and naming (and other things such as use of capitalizations, etc)?

Its nice to have an environment that is as atomicly consistent as Linux where everything is treated as a file. That makes it easy for me to (for personal learning and understanding) build up (and organize) my layers of understanding from "first principles" so to speak.

And, Roberts, thanks for making your wonderful contribution to this crazy world we live in!

[ThinClient]

I have found docs to munch on...thx.