Mixing tcz's and scm's

[caminati]

a tcz extension emulates what in slax is done via aufs by symlinking.
This embeds it in the fhs, allowing it to be a dependency of other tczs.
A scm skips the symlinking step, because less importance is paid to the dependency mechanism.

Ok, it sounds reasonable that two different types of extensions have been conceived, given this rationale.
However, I am in the situation of needing a interdependency mechanism between tcz and scm.

In concrete: I have created a minimal texlive 2012 extension, which I need to be a tcz because of integration with the fhs and because I sometime need to tce-load -ci to do modifications.
I modularized the additional stuff from texlive into scms.
That is because such stuff is made from a myriad of small files, and even just symlinking all of them wastes space (checked that using du /usr/local/texlive).
(by the way, this illustrates another advantage of scm over tcz)

Hence: is it possible to have a tcz as a dependency of a scm?

Currently, it seems it's not...

[tinypoodle]

a tcz extension emulates what in slax is done via aufs by symlinking.

Not really.
symlinking is a much simpler mechanism than overlay filesystems and preceded those by a long time.

[caminati]

a tcz extension emulates what in slax is done via aufs by symlinking.

Not really.
symlinking is a much simpler mechanism than overlay filesystems and preceded those by a long time.

I agree with your last period and I don't see how it contrasts what I said before, hence I don't understand your first period.
With `emulates' I meant that an effect similar to that of overlay filesystems is obtained, without involving the extra complexity needed by aufs.

However, the core of this thread is asking about tcz as a dependency of a scm.
This would probably be too difficult to do, due to recursive deps.
The only possible solution would be to merge tce-load and scm-load scripts into one script based on filename extensions, so that recursion comes for free.