Adhering to the TCL structure; Could dcore merging be possible in the future!?

[xor]

Question 1 - Where are the dependency files of applications downloaded from debian and ubuntu application repositories stored in local content!?

Question 2 - are newly downloaded dependency files overwriting existing older versions!?

Question 3 - dcore u want to remaster iso like TCL how can i do that!?

Question 4 - Can a single application client be created to access debian and ubuntu application repositories at the same time!?

Question 5 - dcore software has huge repositories in terms of support
I think the storage structure of TCL will not be very practical in the long run as it will take a lot of time and manpower to create the same in TCL.

Adhering to the TCL structure; Could dcore merging be possible in the future!?

[xor]

  ?

[Rich]

Hi xor
Do not double post.
Your duplicate post has been removed.

[xor]

I opened the subject in the wrong category,
Please move it to where I wrote !?

General dCore Talk
General discussion of dCore not specific to x86, x86_64, or Armv7
http://forum.tinycorelinux.net/index.php/board,87.0.html

Hi xor
Do not double post.
Your duplicate post has been removed.

[tinycorelinux]

Question 4 - Can a single application client be created to access debian and ubuntu application repositories at the same time!?

This requirement could easily be implemented in a script, and it might not make much sense to implement a single client.

Question 5 - dcore software has huge repositories in terms of support
I think the storage structure of TCL will not be very practical in the long run as it will take a lot of time and manpower to create the same in TCL.

Both dcore and TCL follow the same design philosophy, I believe that the design of such storage structure and package manager may be what users like, even if you and I don't like it very much.

[xor]

application and also dependency files
I don't find it very logical to merge it under a single file.
this situation severely limits portability.

It makes sense to pack dependency files in independent singular forms,
otherwise, I think it will reduce unnecessary time and resource usage during the update process.
(For example, it doesn't make much sense to add the remaining 99 contents to the same zip package after a single file update.)

Question 5 - dcore software has huge repositories in terms of support
I think the storage structure of TCL will not be very practical in the long run as it will take a lot of time and manpower to create the same in TCL.

Both dcore and TCL follow the same design philosophy, I believe that the design of such storage structure and package manager may be what users like, even if you and I don't like it very much.

[xor]

Considering that it changes shape according to TCL standards in both different distributions!
not an unreasonable demand!
but trying to protect the kernel structure of a different distribution,
It will adversely affect the development process of TCL distribution.

New capabilities must be added to TCL!
Frankly, we don't really want debian or ubuntuyu.
The core structure of TCL is more realistic
But because there is so much to do
The need for other 2 large application stores is inevitable.

Question 4 - Can a single application client be created to access debian and ubuntu application repositories at the same time!?

This requirement could easily be implemented in a script, and it might not make much sense to implement a single client.

[tinycorelinux]

(For example, it doesn't make much sense to add the remaining 99 contents to the s

I've been thinking about this for a long time, and it's probably not the package manager's solution today. Especially in today's era of rapid development of network and hardware, many operating systems take the form of full package update, as you said, because a file change is to update the entire package, if more than tens of megabytes or hundreds of megabytes of packages will be, this is not worth the cost.

[xor]

In the subject of update tracking; performance updates are important,

I don't care about security updates;
Because an SD-card with physical write protection helps to overcome all problems.
System reset before and after a possible banking transaction gives a feeling of 100% confidence.

(System vulnerabilities are due to hardware, and they can never be covered by human hands;
maybe artificial intelligence generation; if there were hardware, it could be 99.99% safe, maybe)

dcore; It's like a copy of debian or ubuntu so I don't want to use it.
but it can be used as a very practical tool for TCL.

It would be nice if dcore could give the following options on packaging.
1- just download the app (dependencies will not be downloaded)
2- I'd like the option to create an app's list of dependencies
3- I would like an application to have its dependencies into a single independent file.
4- I would like an application to make its dependencies independent files.
5- I want the option to download and package an application according to TCL standards.

(For example, it doesn't make much sense to add the remaining 99 contents to the s

I've been thinking about this for a long time, and it's probably not the package manager's solution today. Especially in today's era of rapid development of network and hardware, many operating systems take the form of full package update, as you said, because a file change is to update the entire package, if more than tens of megabytes or hundreds of megabytes of packages will be, this is not worth the cost.

[xor]

Since my native language is not English (google translation), some synonyms can be different.
Please answer the questions I asked before
match it with the commands in the "-help" dump below!?

?1- just download the app (dependencies will not be downloaded)
?2- I'd like the option to create an app's list of dependencies
?3- I would like an application to have its dependencies into a single independent file.
?4- I would like an application to make its dependencies independent files.
?5- I want the option to download and package an application according to TCL standards.

Code: [Select]

The  sce-import  and  sce-load  help files are pasted below:

* sce-import --help:
sce-import - Search, convert, install DEB and pre-built packages as local SCEs,
             use simple name (nano not nano_*_i386.deb), may use option combos,
             also see /etc/sysconfig/sceconfig, locale.nopurge and sce.purge.
sce-import             Prompt, enter starting characters of package sought.
sce-import PKG         Search packages that start with desired package name.
sce-import -b PKG      Add resulting SCE to sceboot.lst.
sce-import -c PKG      Search packages that contain desired package name.
sce-import -d PKG      Choose existing SCE(s) to provide dependencies for
                       new SCE, may make new SCE significantly smaller.
sce-import -k PKG      Keep /usr/share/doc and /man in SCE, see man-db.
sce-import -l LISTFILE SCE mega-extension created from text file listing one
                       PKG per line, eg. sce-import -l /tmp/my_apps contains
                       emelfm & nano, which can now share common dependencies.
sce-import -n PKG      Non-interactive exact name import, no combos like -nd.
sce-import -o PKG      Add imported SCE to ondemand via /tce/ondemand script.
sce-import -p PKG      Preserve old DEBINX, no new fetch, better performance.
sce-import -r PKG      Use RAM, swap partition/file to unpack source DEBs.
sce-import -s PKG      Estimate package, HD and RAM space, warn as needed.
sce-import -u PKG      (DEFAULT) update mode, sync new DEBINX files.
sce-import -v PKG      View list of packages the imported SCE contains.
sce-import -z PKG      Ignore locale.nopurge, sce.purge, sceconfig files.
sce-import -R PKG      Include recommended Debian packages, warning large SCE.
sce-import -S PKG      Include suggested Debian packages, warning large SCE.

* sce-load --help:
sce-load - Load SCE(s) and any SCE(s) that it depends on into RAM for use.
           SCEs typically located in /etc/sysconfig/tcedir/sce/.
 
Usage:
 
sce-load             Menu prompt, select SCE to load.
sce-load SCE         Directly load the named SCE.
sce-load SCE1 SCE2   Directly load multiple SCEs.
sce-load -b SCE      Internal use only, to load SCEs at boot time.
sce-load -d SCE      Write any debug information to var/log/sce.log.
sce-load -s SCE      Suppress terminal output during loading process.

[xor]