On 01/14/10 01:43 PM, Bart Smaalders wrote: > On 01/13/10 23:12, Milan Jurik wrote: > >>> In the early phases of the EMI project, we actually considered making >>> /var/svc/manifest a symlink. The feedback that we received, however, >>> indicated that it would no play well with SVR4 packaging. See >>> http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. >>> >>> We also received indications that the symlink would not play well with >>> pkg(5), but I don't have any emails that I can refer you to for that. >>> >> >> But that is problem of packaging system (both of them), which should be >> fixed to deal with such situations (is it the first time when we are >> doing such change on filesystem hierarchy?). Why should we introduce >> such misleading "duplication" of places? Any benefit to have 2 places?
> The issue is that if some package treat /var/svc/manifest as a symlink, > and others as a directory, we'll end up w/ problems. The packaging > system cannot deal with discordant views of the file system hierarchy > in a rational fashion. We can always fix the packages in the wos, but > third parties may deliver SMF manifests to a directory named > /var/svc/manifest for years. It's best that we leave it there to prevent > problems. Right. It makes no sense to place the burden on the project team to fix all Sun-delivered, third-party, and home-grown packaging or install software systems to ensure that they cope with an ARC-Committed directory changing to a symlink. The fact that we have two examples which are not tolerant to it today was taken by the project team as a sign that they should pursue another course of action, and they did. The high-level point here is that we're talking about a filesystem location which is Committed as a delivery directory for ISVs and customers, so it must be handled with care in order to maintain compatibility. liane
