Why do we need both .tce and .tcz ?

[bmarkus]

Do we really need both .tce and .tcz extensions? You can

- mount .tcz
- copy content to RAM
- umount .tcz

It gives the same result as copying it from .tce, just requires a different load option either extension by extension or system wise and would significantly reduce extension creation, maintenance, etc.

[helander]

Good thinking

If this is done I think we should have a boot option that tells how to install (tce or tcz way).
Different install models cloud, hard disk, etc could have different defaults but you should be
able to override the default with the mentioned boot option.

To defer the decision of the install mode to the actual install instead of package creation sounds like a good thing, even if the process to create both types could be automated (in  the build system I use this is automated). However just having to care about one package type when loading the packages onto the system is good. Having the packages in the tce directory and then being able to restart
with some different boot codes to change from tce->tcz install (or vice versa) would be nice (without having to repopulate the tce directory)

Kind Regards

Lars

[bmarkus]

Use two directories, tce and tcz for example. Direcory will define loading mode. You can move extension from one to the other. Just one idea.

EDIT: In general I'm against the bootcode jungle. This is more simple. However you can use two bootcodes to override dirs, copy all to ram and mount all.

[roberts]

While true, you have to realize hindisght is typically better than foresight. TC in very short time has evolved very quickly. Some complain that it moves to quick.

We started with tce, tcz came later. tcz has gone through several iterations, ziofs, cramfs, and now squashfs.

tces being a simple tar archive is much easier for the new user to understand and thus create their first extension. tces are great for quick small personal extensions.

tczs may have embedded user.tar.gz which at first is typically another obstacle for the first time extension maker.

 In the beginning we had limited loop devices to mount. Do you want every little exteions to occupy a loop? How would you automatically determine which tczs to mount/copy/unmount and which to mount and link? Introduce yet another directory or subdirectores to process at boot time? At the present you can easily have both tce and tcz in the same single PPR (tce directory).

I am certainly not against this. Lessening the load for Jason and having a single extension type is nice.

Perhaps the subdirectory approach would allow for an easy transitition and if we standardize on squashfs we would not even need to mount to perform the copy to ram.

[bmarkus]

Robert

thanks for the comments. I think it is worth to go further with this discussion. To have extensions duplicated makes the life complicated for all perties especially for the newcomers and for ordinary users when TC will be matured to a certain level, or distribution based on TC/MC will appear and also makes hard to understand the system.

KISS - Keep It Simple and Smile

Yes, TC's evolution is fast, and it is a beauty for developers (partly), pain for the users (?) 

Regards... Béla

[bigpcman]

Robert

thanks for the comments. I think it is worth to go further with this discussion. To have extensions duplicated makes the life complicated for all perties especially for the newcomers and for ordinary users when TC will be matured to a certain level, or distribution based on TC/MC will appear and also makes hard to understand the system.

KISS - Keep It Simple and Smile

Yes, TC's evolution is fast, and it is a beauty for developers (partly), pain for the users (?)  

Regards... Béla

I agree this deserves discussion. Speaking as a user, I agree migrating to a single type of extension makes a lot of sense. For me tces are in RAM and tczs are in usb flash memory so the tces run faster. I have not measured the exact difference in performance so I can't say if there is enough difference for me to care one way or the other. I wonder if the mounting of the tcz in ram makes it run at an equivalent speed as a tce in ram.

I do think keeping track of versions for the two classes of extensions is harder than it should be for all concerned.

I also think if the tcz creation procedure was turned into a user friendly utility program perhaps with a gui interface the complexity issue would go away.  

[samedirection]

This idea does seem worth pursuing.  And I like bigpcman's suggestion that whatever of the extension creation process can be automated should be.  However I generally find a non-gui process for this kind of thing to be more flexible, and in the end quite a bit user-friendlier than a GUI tool, which is always limited by it's author's imagination.  Scripts + a good tutorial are worth their weight in gold.  (Have a look at the Archlinux or Gentoo Wikis for good examples of this kind of thing.)

And since we're discussiong automation, an elegant build tool (like the one Arch linux has) would let package developers upgrade packages much more easily, since all the work is in setting up the automation initially, after that it runs by itself.  Of course this can be done with scripting, but it seems that arch has taken it one generalization level further, resulting in a build process that is customized to the particularities of each extension, but also does all the appropirate safety and sanity checks.  Just an idle thought.

[helander]

Please, have a look tcbuild a very nice and simple build tool for extensions made by SvOlli.  He announced it here on the form a few months ago and I have used it and tailored it to my own needs since that day. It is a tool in the same spirit as PKGBLD (Arch) and SLACKBUILD (slackware).

/Lars

[kacper]

I can agree on that a single extension type would reduce extension creation and maintenance time. It´s hard enough to keep track of all the additional files for a single extension type. At least when one is creating libraries and splitting the package into one run and one dev package - it quickly becomes a mess of all the files.

[florian]

I too think we should reduce numbers of extension versions as tcz can be used also to load in RAM.

TC would handle both types of extension, however there should be only one online repository instead of two. The repository would contain only the .tcz* extension (normal case) OR the .tce* version (only in case the tcz version is not available)

[roberts]

Will tread lightly at first. Perhaps next RC.

[jpeters]

Personally, I like the separation since it offers more choice. Sometimes a tcz won't work, whereas a tce will (eg, perl_xml.tcz if you've installed wine.gl.tczm; qt-4.5-base.tcz ---some conflict not present with qt-4.5-base.tce).   I like to use tce's when they're small, even if a tcz is available.  Choice might include how fast your computer is, RAM, etc.

I'll choose a tcz for temporary usage for frequent install/uninstall events.  I'm not sure which is better regarding disk corruption, which is not infrequent.  The tce folder (and backup) require frequent repair or you'll loose data.

[florian]

Personally, I like the separation since it offers more choice.

Personally, I'm not sure what choice two parallel repositories actually offer. This is because as bmarkus noted in the first post of this thread, you should be able to do everything when a tcz is available: either load it (in RAM) or mount it.

Sometimes a tcz won't work, whereas a tce will

In my humble opinion this is precisely why we should have only one repository instead of two. If we have one extension that wouldn't work, the faulty extension would get fixed quicker.


There are at least two other issues I see with our two repositories:

1) Handling tce and tcz in parallel, and two dependencies files, and two md5sum files, and two descriptions is very cumbersome. I think this is preventing more people to contribute extensions.

2) We have two universes that are mostly parallel... but not entirely. And when they meet, it creates problems. As an example, the other day I was looking for the midnight commander application. Unfortuntely I didn't find it in the universe I usually use (tcz repo). It could have been the end of story, but I actually know that TC users are expected to look at TWO directories in order to find one app (!!). And indeed mc was in the other repo. So I downloaded it. Unfortunately not only it didn't work, but it started to make some other programs stop functioning to. Very frustrating. The reason was that mc uses glib1, so it downloaded it as a dependency. But I had glib1 installed already as a tcz because of some other programs.  Luckily I quite quickly realized what was happening and found out the glib1.tce, removed it, and rebooted, but really it's a lot of frustration and fix for using a simple app.

With one single repository, even if mc had not been available as tcz, this problem would not have existed.

[jpeters]

In my humble opinion this is precisely why we should have only one repository instead of two. If we have one extension that wouldn't work, the faulty extension would get fixed quicker.

I wouldn't want to eliminate tcz extensions altogether because there's a conflict in my personal setup. There's lots of variation regarding conflicts for a variety of setups.  

1) Handling tce and tcz in parallel, and two dependencies files, and two md5sum files, and two descriptions is very cumbersome. I think this is preventing more people to contribute extensions.

I won't argue, but think that's unlikely. It take a few seconds to create the second md5sum file, & the info file is almost the same.

We have two universes that are mostly parallel... but not entirely. And when they meet, it creates problems. As an example, the other day I was looking for the midnight commander application. Unfortuntely I didn't find it in the universe I usually use (tcz repo). It could have been the end of story, but I actually know that TC users are expected to look at TWO directories in order to find one app (!!). And indeed mc was in the other repo. So I downloaded it. Unfortunately not only it didn't work, but it started to make some other programs stop functioning to. Very frustrating. The reason was that mc uses glib1, so it downloaded it as a dependency. But I had glib1 installed already as a tcz because of some other programs.  Luckily I quite quickly realized what was happening and found out the glib1.tce, removed it, and rebooted, but really it's a lot of frustration and fix for using a simple app.

With one single repository, even if mc had not been available as tcz, this problem would not have existed

Appbrowser doesn't install a second copy, & checks only the root.

Personally, I keep a combined local database & use "update -i" unless I want to view an info file where I use appbrowser.  I do like the inclusion of both tcz & tce files to choose from, however.  

[bigpcman]

Would it be possible to only have tcz's in the repository but to augment the tcz format such that it could easily be converted by the installer into a tce if desired?

edit: Further to my point, the installer could be made responsible for the installation format per the users instructions once the repository format is settled.