Migrating to recursive .dep files

[bmarkus]

Now, as 2.10 supports recursive dependency resolution teh question is how are we introducing it. Recursive resolution is a very important feature we have been waiting for. Extensions must be listed as a dependency only where they are really needed, but not at the top level. It makes dep file not only shorter but the whole process must more realible. If dep list is changed in a certaine xtension, no need to follow up the changes in all other extensions where this extension is used. Great!

Best way to convert dep list to do it manually by the extension creator who knows which are the real dependencies and which are indirect. I'm ready to adjust my dep lists and to submit new extensions and updates with the recursive list.

Good point that 2.10 works fine with both old (flat) and new (recursive lists), so no nned to convert all in one step.

Drawback is, that once a dep list is recursive, it will cause a problem for versions prior 2.10 so migration of existing installations is essential.

Robert, Jason@

what is the plan for migration?

[Jason W]

That sounds pretty much like the plan as I understand it, for new extensions to have recursive dep files and the existing ones to be adjusted by the extension maker and submitted, and for the info file to indicate that the extension has recursive deps. 

[roberts]

Since, flat, top level is still supported, I would think that only those extensions that have been converted would need to indicate such in their info file. As I posted all users are strongly encouraged to upgrade to v2.10. As extensions are converted to recursion the use of v2.10 or better will be required. Let the conversion to recursion begin.

[Jason W]

Oh, and for those extensions that are in the gmail account, I will go ahead and post them so I don't get behind on it.  But please send updated dep files.

[Juanito]

I guess it would be good to highlight that with recursive deps, all the extensions in a folder will need their associated dep files to be present, whereas with the old style deps only the dep file for the extension being loaded was required.

[bmarkus]

I guess it would be good to highlight that with recursive deps, all the extensions in a folder will need their associated dep files to be present, whereas with the old style deps only the dep file for the extension being loaded was required.

You are right. Normally it is managed by AppBrowser, but if you are placing a .tcz into /tce/optional related .tcz.dep has to be placed too.

[thane]

So in TC 2.10 does tce-update now place .tcz.dep files in the tce/optional directory?

[roberts]

Since version 2.8 we have had a single directory tce/optional so as not to have multiple dep file locations.

[combo3]

That sounds pretty much like the plan as I understand it, for new extensions to have recursive dep files and the existing ones to be adjusted by the extension maker and submitted, and for the info file to indicate that the extension has recursive deps. 

Just for clarification, does this mean just a general note that there are recursive deps, or a detailed list of which deps are recursive?

Been away for a while, so apologies if this has been explained elsewhere.

[Jason W]

With mine I am adding to the changelog something like "2010/03/23  Converted to recursive deps" , like any other update or change.  Since there are so many, I don't think there is a point announcing each one of them in the forum, that time is better spent on other things.

Each extension that has it's dep file altered to recursive will get that label, not just the top level one.

[bmarkus]

I started to indicate in .info not only that .dep is recursive or converted to recursive but even if there are no dep file. My info files look like:

Title:          pyusb.tcz
Description:    USB access extension module
Version:        0.4.2
Author:         Wander Lairson Costa
Original-site:  http://pyusb.berlios.de
Copying-policy: BSD
Size:           16k
Extension_by:   bmarkus
Comments:       Binaries only
                ----
                Compiled for TC2.x
                ----
                PPI compatible
                ----
                Dep file is recursive
Change-log:     2010/03/03 First version
Current:        2010/03/22 Dep file converted to recursive

Title:          mutt.tcz
Description:    Powerful text-base mail client
Version:        1.4.2.3
Author:         Various, see source for more info
Original-site:  http://www.mutt.org
Copying-policy: GPLv2
Size:           332k
Extension_by:   bmarkus
Comments:       Binaries only
                ----
                Compiled for TC2.x
                ----
                PPI compatible
                ----
                Dep file is recursive
Change-log:     ----
Current:        2010/03/18 First version

Title:          mutt-doc.tcz
Description:    Powerful text-base mail client
Version:        1.4.2.3
Author:         Various, see source for more info
Original-site:  http://www.mutt.org
Copying-policy: GPLv2
Size:           496k
Extension_by:   bmarkus
Comments:       Doc files
                ----
                Compiled for TC2.x
                ----
                PPI compatible
                ----
                No dep file
Change-log:     ----
Current:        2010/03/18 First version

[combo3]

Thanks for the replies. For consistency and easier readability, I'm wondering if it might be useful to move dependencies and ppi compatiblity out of "comments" and into separate header categories.

Using bmarkus example:

Title:          pyusb.tcz
Description:    USB access extension module
Version:        0.4.2
Author:         Wander Lairson Costa
Original-site:  http://pyusb.berlios.de
Copying-policy: BSD
Size:           16k
Extension_by:   bmarkus
Depends: Dep file is recursive
PPI Compatible: Yes
Comments:       Binaries only
                ----
                Compiled for TC2.x
                ----
             
             
Change-log:     2010/03/03 First version
Current:        2010/03/22 Dep file converted to recursive

[maro]

I strongly support the suggestion of combo3 to include a PPI compatible: YES|NO entry in the header section of the .info files.

WRT the recursive dependencies I'm not so sure. The conversion will happen over the next few weeks (maybe month), but will only be for a limited time. Moving forward all extensions will use recursive dependencies. And for the upcoming TC 3.x series I imagine the non-recursive .dep files will be seen as a thing of a long lost past. Having a note in the change-log section might be the appropriate thing to do (if required at all).

[bmarkus]

WRT the recursive dependencies I'm not so sure. The conversion will happen over the next few weeks (maybe month), but will only be for a limited time. Moving forward all extensions will use recursive dependencies. And for the upcoming TC 3.x series I imagine the non-recursive .dep files will be seen as a thing of a long lost past. Having a note in the change-log section might be the appropriate thing to do (if required at all).

Agree. Non-recursive deps will go away, to have mixture of them just temporary. In longer term I can imagine there will be still few non-recursive dep fiels of less freuently used or updated extensions but it will not harm. Also you can establish some rules for commonly used extensions. If gtk2.tcz listed you can safel remove its dependency. Same with python.tcz and few others.  So indication of recursive status is just fine in comment.

This is another question to use an enhanced .info file format in the future, which is worth to discuss.