Re: virtual package versions?
Manoj Srivastava <srivasta@datasync.com> 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 debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: