why don't remove .tcz from the dep files since all extensions are now .tcz?

[jls]

 

[robc]

I asked this question too, didn't get a response... http://forum.tinycorelinux.net/index.php?topic=4611.msg24183#msg24183

[neonix]

1. There are existing users who use previous versions of TC and they have customised system to use *.tcz or even *.tce
2. It's too much work.
3. I belive that in 3.x version they create new repository without tcz.

[bmarkus]

2. It's too much work.

What is too much work? If you mean to convert existing .dep files just a simple script can do it in few seconds.

[robc]

1. There are existing users who use previous versions of TC and they have customised system to use *.tcz or even *.tce

That's what an appbrowser.tcz would/could be used for

2. It's too much work.

using a shell script with a single sed line in a for loop could convert all .dep files
ie:

Code: [Select]

#!/bin/sh
mkdir olddeps
for f in $( ls /path/to/deps ); do
mv $f olddeps
sed 's!\.tcz!!' olddeps/$f >$f
done

[MakodFilu]

I would tend to agree, but I have two objections:

1) If sometime in the future a new type of extension is developed, that would mean those changes to .dep files should be reversed?

2) AFAIK no single .dep file is above 512 bytes. Not even before recursive dependencies. That means it doesn't matter how much you could shrink it: every time something changes in there, a whole cluster would be written.

[bmarkus]

2) AFAIK no single .dep file is above 512 bytes. Not even before recursive dependencies. That means it doesn't matter how much you could shrink it: every time something changes in there, a whole cluster would be written.

There are. And there are few above 1K, see rhythmboxtcz.dep or gnome-desktop-base.tcz.dep which are not yet recursive.

[MakodFilu]

You got me there, but I still think compression and not stripping would be the key here, be it placing it inside the .tcz (or another future package format) or getting .dep files gzipped.

[robc]

You got me there, but I still think compression and not stripping would be the key here, be it placing it inside the .tcz (or another future package format) or getting .dep files gzipped.

I think placing the dep files within the extension itself is a good idea. This would give a more complete 'package'. But I would say something like that would have to wait for 3.x since it would be too much change to the way extensions are handled.

As for compressing them, I think that is too much cpu usage for little gain.

[curaga]

How would one check for the deps before download if they were inside?

[MakodFilu]

I remember something about Apache (and by extension, other servers) providing transparent usage of gzipped webs.

About dependencies inside the package, that is the way it *seems* to be with .deb and .rpm packages, BUT neither of those is a Squashfs. Besides, that may be the very reason of why .deb packages are composed of one tar.gz for the program itself and *another* smaller one for meta info ( i.e. dependencies).

All that means there will be a future Core package format, later or sooner, which makes the discussion about removing .tcz from .dep's a pointless one.

[^thehatsrule^: removed empty attachment]