metapackages ?

[helander]

Other distros supports what some of them call metapackages. A "metapackage" is a package that lists a number of other (real- or meta-) packages and if you install the metapackage all of the listed packages will be intstalled.

To me this could easily be achieved using a .dep file and my question is:

    is it enough with the "metapackagename.dep" file or do I also have to have a "metapackagename.tce" ?

    in the latter case what is the minimal required content of the .tce file ?


Kind Regards

/Lars

[Jason W]

We have not made a metaextension yet, but it has been discussed.  It would need at least one file in a .tce, not just a dep file.  Say for instance /usr/local/share/extension.readme.  That way there is a tce to extract.  The deps would have to be real extensions though, as dependency resolution is not recursive.  A GNU type of extension to replace busybox is one such metaextension that may eventually come into being.

[helander]

Thank you very much for the info.

Kind Regards

/Lars

[tobiaus]

you (that is, anyone that makes extensions) could make one right now though, couldn't you? just make a "tce" with a file, then write the .dep list. nothing modified to the usual system, it will install a file and then download all the "deps." voila metapackage. you could say in the info file: "contains no packages itself, but loads... (a list of the extensions it loads)"

[helander]

Yes, I had that in mind. It would be great if TC would support to load extensions recursively based on the .dep files, then the metapackages would be much simpler (not so much to create as to maintain).

/Lars

[tobiaus]

It would be great if TC would support to load extensions recursively based on the .dep files, then the metapackages would be much simpler (not so much to create as to maintain).

i can think of a use for a metapackage, but i can't think of one so important that it would require greater sophistication than all the other packages, which do fine with non-recursive deps. i don't even like recursive deps, you know how annoying it is trying to download .deb packages for ubuntu when the deps are recursive, or even behave as though they're recursive?

[helander]

Unfortunately, you do not really have choice since the need for recursiveness depends on the dependencies between packages; and the packages available out there have  multi-level dependencies. You can of course make a choice to just support one dependency level, but it then leaves you to manually manage the other levels. If that is the way TC is going to be, I can live with that. Simplicity could be important too.

/Lars

[Jason W]

Robert had made dep resolution non-recursive on purpose for the sake of simplicity.  It is the path of least surprise.  That is you can look at a .dep file and know exactly how many extensions that app will install along with it.  With recursive deps, you wouldn't have much of an idea how many other extensions would get installed along with the first one.

[tobiaus]

you do not really have choice since the need for recursiveness depends on the dependencies between packages;

the greatest difference between recursiveness and non-recursiveness is (usually) for the user.  as jason mentions if you have recursive deps then you have no idea when you're done downloading things until you've downloaded them, and then downloaded those... and then...

this made my first experience with ubuntu intolerable, i didn't have an internet connection, i was (by definition) a noob, and i had to download packages in windows. in tc that would be no problem, just download one extension, look at the dep list, and grab that list of packages. but even though it's "recursive" for apt, etc (and the user that has to do apt's job) it's really not much different. apt has a database that lists all the deps for all packages, and apt consults this list.

instead of having one great database, we have one tiny database for each extension. it does make tc very simple actually, and although apt may have lots going for it, i really prefer the simple beauty of tc. if we did recursive deps, every time we wanted to tell someone how to install minefield manually, we'd still need to list every dep in one place for them to download, so we'd be using documentation to make up for the new lack in our "package management system" which (as things are) has its own tiny database with all the dep info needed for each extension. (don't underrate this.)