Re: per-architecture Provides field

2006-04-13 Thread Erast Benson 
On Thu, 2006-04-13 at 00:04 +0200, Loïc Minier wrote:
 Hi,
 
 On Wed, Apr 12, 2006, Erast Benson wrote:
  +Provides: sunwlxsl [solaris-i386]
   Depends: ${shlibs:Depends}
 
  Why not simply use Provide: ${misc:Provides} and set misc:Provides to
  sunwlxsl on solaris-i386? 

OK. This was a missing hint I were looking for. Thanks!

  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? And I'd like to
putback libxslt change (and similar) to upstream, so other derivative
will not be polluted with mis-provided packages.

-- 
Erast


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: per-architecture Provides field

2006-04-13 Thread Daniel Stone 
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? And I'd like to
 putback libxslt change (and similar) to upstream, so other derivative
 will not be polluted with mis-provided packages.

So why not have an OpenSolaris core set of metapackages, with a sunwlxsl
package that Depends on libxslt1, instead of polluting every package
with this port-specific stuff?


signature.asc
Description: Digital signature

Re: per-architecture Provides field

2006-04-13 Thread Matthew Palmer 
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.

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?

- Matt

Re: per-architecture Provides field

2006-04-13 Thread Erast Benson 
On Thu, 2006-04-13 at 12:18 +0300, Daniel Stone 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? And I'd like to
  putback libxslt change (and similar) to upstream, so other derivative
  will not be polluted with mis-provided packages.
 
 So why not have an OpenSolaris core set of metapackages, with a sunwlxsl
 package that Depends on libxslt1, instead of polluting every package
 with this port-specific stuff?

Indeed. I think this is a right way to go, and in fact, would be easier
to maintain over time, since all glue meta information would be
concentrated in one place.

-- 
Erast


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: per-architecture Provides field

2006-04-13 Thread Erast Benson 
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]

Re: per-architecture Provides field

2006-04-12 Thread Loïc Minier 
Hi,

On Wed, Apr 12, 2006, Erast Benson wrote:
 +Provides: sunwlxsl [solaris-i386]
  Depends: ${shlibs:Depends}

 Why not simply use Provide: ${misc:Provides} and set misc:Provides to
 sunwlxsl on solaris-i386?  Why not simply Provide: sunwlxsl all of the
 time, doesn't it provide sunwlxsl on other arches?

   Cheers,
-- 
Loïc Minier [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]