Manoj Srivastava <[EMAIL PROTECTED]> wrote: > Umm, I have misgivings about packages providing multiple > (virtual) versions. A real package can only provide one version, > virtual packages should not have more priviledges.
But what's to prevent a real package from providing multiple virtual packages? Or multiple instances of the same virtual package? If one but not the other, why would these be distinct cases? > Also, I would like to consider separating the name spaces of the > virtual and concrete packages, as far as possible; very rarely can a > package emulate another to justify it ``providing'' the other real > package. In these cases, both packages should provide a new "virtual" > package, and dependents depend on the virtual package. You mean like (looking at examples where virtual packages versions would be immediately useful): unzip-crypt shouldn't provide unzip? > Allowing all names to be potentially virtual is something we > shall regret, I fear. You may be right. Do you have any reasons other than clarity of terminology? > Also, we should not dilute the semantics of the conflict just > for virtual packages -- I think that is playing with system > stability, in the long run. In fact, I think this would break some existing cases (but I've been too lazy to attempt to track these down). > I am for versioned virtual packages, but only if the strict > versioning semantics that apply to normal packages also apply to > them, anything else may impact apt. Any implementation of versioned virtual packages will impact apt. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
