[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: per-architecture Provides field

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.<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


Reply to: