On Thu, 2006-04-13 at 17:41 +1000, Matthew Palmer wrote: > On Thu, Apr 13, 2006 at 12:13:57AM -0700, Erast Benson wrote: > > On Thu, 2006-04-13 at 00:04 +0200, Loïc Minier wrote: > > > Why not simply Provide: sunwlxsl all of the > > > time, doesn't it provide sunwlxsl on other arches? > > > > But how? sunwlxsl is something which is only present in > > OpenSolaris-based derivatives, such as NexentaOS? > > Assuming that the virtual package 'sunwlxsl' doesn't have conflicting > meanings on different architectures, I see no reason not to provide the > virtual package on all architectures. Non-OpenSolaris derived architectures > may ignore the virtual package entirely, but that isn't harming anything.
Its not harming, yes, but it will show up as an unrelated info. > I'm a bit confused about why you need to Provide a crazy sun package name, > though -- are you intending for the Debian packaging system to integrate > with the "native" packaging system somehow, and the two to cooperate? Not exactly having two packaging system installed. There are two reasons for those virtual package names: 1) Utilize existing SVR4 packages; Since a lot of software comes as SVR4 packages, they needs to be seamlessly installed on NexentaOS without too much pain for end user. It includes third party kernel drivers like 3c9xx, user space stuff like JRE/JDK, Oracle, Sun Studio, NetBeans, StarOffice, etc We already extended "alien" package to fully support SVR4 conversion, now I'm thinking of the way to provide utilities set which will do such an installation on the fly. I.e. it will be based on SVR4 utilities interfaces but backend will be in Debian format. i.e. instead of "dpkg -i <package>" user will call "pkg_add -d <package>" and pkg_add will do on the fly conversion into .deb with subsequent dpkg -i ... invocation. Since outside packages assumes SVR4 core packages to be present, we need to provide virtual names to make such an installations possible. 2) Make OpenSolaris core happy and share some common packages. OpenSolaris core has 200+ and number is growing as Sun keep open sourcing new code according to their Roadmap[1]. Those packages has interdependence as per original SVR4 meta organization. It also includes packages which could be shared outside of core. Good examples are libxml2, libxslt, perl, etc which are in native SVR4 form looks like accordingly sunwxml, sunwxslt, sunwperl, etc. Therefore, to share common packages we need to provide virtual names and virtual names should match original crazy names because of internal core dependencies and possible outside packages (1). To make all this work cleanly, we are thinking to extent dpkg (related bug [2]) with modified conffiles format as: <conf-file> [action-class-name] [action-class-name] is similar behavior to original SVR4 specification, i.e. i.<name> - invoke when conffile gets installed r.<name> - invoke when conffile gets removed ... Once we have the above implemented, it would be trivial to cleanly convert SVR4 packages on the fly, so this would a prerequisite for (1). [1] http://www.opensolaris.org/os/about/roadmap/;jsessionid=D1646BB78DB118643221400DA73B6286 [2] http://www.gnusolaris.org/cgi-bin/trac.cgi/ticket/176 -- Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
