Subject: [Netmod-ver-dt] Resolving package conflicts

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 11 Sep 2019 09:59:31 +0000

In the packages draft it is possible to for a package definition to combine modules from two separate packages which may conflict.  I.e. more than one version of a module might end up in the resultant package, or the import dependencies might need to be fixed.

This is OK, because the packages draft requires that these conflicts are always explicitly resolved by listing the specific module versions in the combined package, so the problem is solved.

But what about if we define a package [email-masked]<mailto:[email-masked]> that contains, say, 10 modules?

This package might be imported by a hypothetical [email-masked]<mailto:[email-masked]>.

Separately there might be a hypothetical [email-masked]<mailto:[email-masked]> package that has been published later and uses an updated version of ietf-base package, say [email-masked]<mailto:[email-masked]>, that may contain BC updates to several of the modules.

Say a device wants to implement a [email-masked]<mailto:[email-masked]> module that imports both [email-masked]<mailto:[email-masked]> and [email-masked]<mailto:[email-masked]>.  Currently the packages draft would require the my-packages definition to explicitly re-state each of the modules in [email-masked]<mailto:[email-masked]> that differed [email-masked]<mailto:[email-masked]> (because only a single version of a module can be implemented, and all conflicts must be explicitly resolved).

This works, but I'm wondering whether that might become overly verbose.  Hence, I'm thinking that it might be useful for the [email-masked]<mailto:[email-masked]> definition to explicitly list [email-masked]<mailto:[email-masked]> as a direct package import, stating that it is replacing [email-masked]<mailto:[email-masked]> (which is indirectly imported via [email-masked]<mailto:[email-masked]>).  Avoiding the need to explicitly list the conflicting modules.  In fact, we could require that all conflicting imported package versions must also be explicitly resolved, just like for modules.

Does anyone have any objections to this?

Thanks,
Rob

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 11 Sep 2019 17:55:22 +0000

On Sep 11, 2019, at 05:59, Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:

Say a device wants to implement a [email-masked]<mailto:[email-masked]> module that imports both [email-masked]<mailto:[email-masked]> and ietf-l2vpn@1..0.0<mailto:[email-masked]>.  Currently the packages draft would require the my-packages definition to explicitly re-state each of the modules in [email-masked]<mailto:[email-masked]> that differed [email-masked]<mailto:[email-masked]> (because only a single version of a module can be implemented, and all conflicts must be explicitly resolved).

This works, but I’m wondering whether that might become overly verbose.  Hence, I’m thinking that it might be useful for the [email-masked]<mailto:[email-masked]> definition to explicitly list [email-masked]<mailto:[email-masked]> as a direct package import, stating that it is replacing [email-masked]<mailto:[email-masked]> (which is indirectly imported via [email-masked]<mailto:[email-masked]>).  Avoiding the need to explicitly list the conflicting modules.  In fact, we could require that all conflicting imported package versions must also be explicitly resolved, just like for modules.

I think that sounds very reasonable and much less cumbersome than enumerating individual modules.

Joe

Thanks,
Rob

_______________________________________________
Netmod-ver-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod-ver-dt