.dep files and tce:s vs tcz:s

[helander]

If I have understood how TC currently works with respect to .dep files, then if package A depends on package B, in A.dep I must not only specify package B but also what package format of the package to use (.tce, .tce, .tcel, ...).

If the above is not true, then you could probably discard the rest of this message - but I would be very happy to get some feedback on how .dep files are processed in today's TC.

I see a couple of cons with the scheme above, among them are

• Having to maintain two versions of the .dep file - one for tce repo and one for tcz repo
• If the provider of package B suddenly decides to change from .tce to .tcel then all existing .dep files will be "broken"
• If I have installed B.tcz and would like to install A.tce that has B.tce in its .dep file, that will fail. I do not think it should fail - or is there any reason for not supporting a mix of tce:s and tcz:s
• In general the logical dependency are among packages and the actual physical dependency is in the files installed on the system. TCE:s and TCZ:s are just different ways to transport the data, and if a package is in format this or that should not really have an impact on what could/should be used.

I would like to propose the following scheme for use in TC. It adresses the issues mentioned above and is also backwards compatible with the current .dep files.

The scheme:

• In general a .dep file contains a list of package names and not package file names, i.e. the extensions (tce, tcz, tcel, ...) are omitted from the packages listed in the .dep file.
• It is however fully legal to include the extensions as today (for backwards compatibility and for some more precise control if so required
• In case the extension is given, then TC only tries to install from package files having that exact extension
• If no extension is given, TC tries to install from a package file having the same "repo type (e or z)" as the selected main package. The main package is the package the user selected to install.
• If no extension is given and the package is already installed (in either file format) then just accept that it is already installed.
• If and extension is given and a package is installed from a "wrong" file format, then I guess it would be best to refuse the install and issue some appropriate warning

Any thoughts?

/Lars

[Juanito]

If I have understood how TC currently works with respect to .dep files, then if package A depends on package B, in A.dep I must not only specify package B but also what package format of the package to use (.tce, .tce, .tcel, ...).

True - The dep file for an extension should load all required files for the extension to work, which implies listing all related dependencies. At the moment, the dep file for a tce extension should contain tce extensions and the dep file for a tcz extension should contain tcz extensions

I see a couple of cons with the scheme above, among them are

1. Having to maintain two versions of the .dep file - one for tce repo and one for tcz repo
2. If the provider of package B suddenly decides to change from .tce to .tcel then all existing .dep files will be "broken"
3. If I have installed B.tcz and would like to install A.tce that has B.tce in its .dep file, that will fail. I do not think it should fail - or is there any reason for not supporting a mix of tce:s and tcz:s
4. In general the logical dependency are among packages and the actual physical dependency is in the files installed on the system. TCE:s and TCZ:s are just different ways to transport the data, and if a package is in format this or that should not really have an impact on what could/should be used.

1. - True, but not too big a deal
2. - True, but it shouldn't happen too often
3. - I don't think so - the logic is that tce-load checks if an extension is already loaded (tce or tcz) and skips the dependency if it is already loaded.
4. - see 3. above

I would like to propose the following scheme for use in TC. It adresses the issues mentioned above and is also backwards compatible with the current .dep files.

The scheme:

1. In general a .dep file contains a list of package names and not package file names, i.e. the extensions (tce, tcz, tcel, ...) are omitted from the packages listed in the .dep file.
2. It is however fully legal to include the extensions as today (for backwards compatibility and for some more precise control if so required
3. In case the extension is given, then TC only tries to install from package files having that exact extension
4. If no extension is given, TC tries to install from a package file having the same "repo type (e or z)" as the selected main package. The main package is the package the user selected to install.
5. If no extension is given and the package is already installed (in either file format) then just accept that it is already installed.
6. If and extension is given and a package is installed from a "wrong" file format, then I guess it would be best to refuse the install and issue some appropriate warning

For me:

1. OK
2. Not sure I understand
3. Not sure I understand
4. Makes sense for me
5. I believe that is already the case today
6. But why specify an extension type if we follow the logic of 4. above?

Of course this is only my opinion and I'm not the one to modify the script...

[mikshaw]

TCE:s and TCZ:s are just different ways to transport the data, and if a package is in format this or that should not really have an impact on what could/should be used.

You seem to have misundertood the purpose of having the two formats.  It's not a matter of transport (like with gzip vs. bzip2), but a matter of how they are used after transit.  TCZ are often used because of limited ram, so having a TCE-type dependancy for TCZ is contrary to this use.

[helander]

TCE:s and TCZ:s are just different ways to transport the data, and if a package is in format this or that should not really have an impact on what could/should be used.

You seem to have misundertood the purpose of having the two formats.  It's not a matter of transport (like with gzip vs. bzip2), but a matter of how they are used after transit.  TCZ are often used because of limited ram, so having a TCE-type dependancy for TCZ is contrary to this use.

So what you are saying that it should not be allowed to use combinations of TCE and TCZ in the same system?

I do not really see a need to enforce such restrictions and I have seen suggestions in this forum that proposes solutions  such mixed solutions, so I guess people out here actually have systems configured like this.

[mikshaw]

So what you are saying that it should not be allowed to use combinations of TCE and TCZ in the same system?

I'm not saying it should not be allowed -- I'm an advocate of user choice, and it's likely that little harm will be done by mixing them (although it's just as likely that a few TCZs won't get along with certain TCEs).  I'm just saying that there is a logic behind using two types of dependancies because the two types of extensions are installed in two different ways, for different reasons.

[helander]

If I have understood how TC currently works with respect to .dep files, then if package A depends on package B, in A.dep I must not only specify package B but also what package format of the package to use (.tce, .tce, .tcel, ...).

True - The dep file for an extension should load all required files for the extension to work, which implies listing all related dependencies. At the moment, the dep file for a tce extension should contain tce extensions and the dep file for a tcz extension should contain tcz extensions

I see a couple of cons with the scheme above, among them are

1. Having to maintain two versions of the .dep file - one for tce repo and one for tcz repo
2. If the provider of package B suddenly decides to change from .tce to .tcel then all existing .dep files will be "broken"
3. If I have installed B.tcz and would like to install A.tce that has B.tce in its .dep file, that will fail. I do not think it should fail - or is there any reason for not supporting a mix of tce:s and tcz:s
4. In general the logical dependency are among packages and the actual physical dependency is in the files installed on the system. TCE:s and TCZ:s are just different ways to transport the data, and if a package is in format this or that should not really have an impact on what could/should be used.

1. - True, but not too big a deal
2. - True, but it shouldn't happen too often
3. - I don't think so - the logic is that tce-load checks if an extension is already loaded (tce or tcz) and skips the dependency if it is already loaded.
4. - see 3. above

I would like to propose the following scheme for use in TC. It adresses the issues mentioned above and is also backwards compatible with the current .dep files.

The scheme:

1. In general a .dep file contains a list of package names and not package file names, i.e. the extensions (tce, tcz, tcel, ...) are omitted from the packages listed in the .dep file.
2. It is however fully legal to include the extensions as today (for backwards compatibility and for some more precise control if so required
3. In case the extension is given, then TC only tries to install from package files having that exact extension
4. If no extension is given, TC tries to install from a package file having the same "repo type (e or z)" as the selected main package. The main package is the package the user selected to install.
5. If no extension is given and the package is already installed (in either file format) then just accept that it is already installed.
6. If and extension is given and a package is installed from a "wrong" file format, then I guess it would be best to refuse the install and issue some appropriate warning

For me:

1. OK
2. Not sure I understand
3. Not sure I understand
4. Makes sense for me
5. I believe that is already the case today
6. But why specify an extension type if we follow the logic of 4. above?

Of course this is only my opinion and I'm not the one to modify the script...

My main issue is that the dep files should NOT contain extensions.
Since today's .dep files do have extensions there needs to be a migration strategy. Let's say that from release X and onward TC supports .dep WITHOUT extensions. When X is released there is still lots of .dep files out there with extensions in them, so TC needs to handle that as well. In release X+N TC could state that .dep files with extensions are no longer supported OR continue to allow them forever. If they should remain the semantics of their use must be defined and hopefully match with today's semantics.

As said above, the most important thing as I see it is that you should not have to specify extensions in the .dep files and that the relevant applications, e.g. appbrowser, will be able to install packages based on .dep files without specified extensions.

In case TC support a mixture of TCE and TCZ in that same system, optional use of extensions in the dep files could be used to express such forced mixing. This is however of far less signficance (for me at least) than the ability to have extensionless .dep files.


/Lars

[Jason W]

As Juanito mentioned, if a gtk2.tczl is installed and you want to install firefox.tce, the tcz version of gtk2 would satisfy the dependency of gtk2 even though gtk2.tcel is in the dep file of Firefox.

So already it functions as if the name of the dependency is gtk2 instead of gtk2.tcel.  And though if extension was later called gtk2.tce that would cause breakage, but renaming the extension name would cause breakage in any case even if the extension suffix was not in the dep file.

[helander]

As Juanito mentioned, if a gtk2.tczl is installed and you want to install firefox.tce, the tcz version of gtk2 would satisfy the dependency of gtk2 even though gtk2.tcel is in the dep file of Firefox.

That sounds fine.

... but renaming the extension name would cause breakage in any case even if the extension suffix was not in the dep file.

I am not sure what you mean by this?

It seems like all .dep file for TCE-type packages today have extensions of TCE-type and the same pattern goes for TCZ-type .dep file (contains TCZ-type extensions) so from that perspective the extensions could be viewed as redundant. Why not just skip the extensions and implement this default behavior in the loaders. The loaders will then need to have the logic to find out the proper extension, but that should not be rocket science. Then an extension change will not be noticed by the users and you could have identical .dep files for TCE and TCZ type packages.

/Lars

[^thehatsrule^]

In other words, if one changes an extension name that's used in a .dep, all of those .dep's will require changing as well.

They are different because what's available as tce's do not necessarily have to exist as tcz's and vice versa.  I'm not sure how much of that holds atm, but it allows for flexibility and it doesn't add much of a difference to the extension maker.