Hi,
I'm packaging a database wrapper library (http://oss.devit.com/yada/).
Its purpose is to provide one single API to a program and let the user
configure if the database used is actually postgres/mysql/sqlite. The
actual interfacing with the databases is done by .so plugins that are
dlopened at
On Fri, Jan 05, 2007 at 05:37:56PM +0100, Christoph Berg <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> I'm packaging a database wrapper library (http://oss.devit.com/yada/).
> Its purpose is to provide one single API to a program and let the user
> configure if the database used is actually postgres/mysql
Re: Mike Hommey 2007-01-05 <[EMAIL PROTECTED]>
> How good does it support it when its plugins can't load, which is going
> to happen if you load, for example, the mysql plugin and don't have the
> libmysqlclient installed ?
Yada returns ENOENT like it does if the user specifies a non-existant
plug
Am Freitag 05 Januar 2007 17:37 schrieb Christoph Berg:
> The alternative solution would be to put the plugins into separate
> packages and then depend on libyada-mysql | libyada-postgres |
> libyada-sqlite. As these packages would merely contain a single file,
> that seems bloat to me.
Kind of th
Re: Hendrik Sattler 2007-01-05 <[EMAIL PROTECTED]>
> The thought should not be how many files are in each package but what the
> average client saves by not pulling all dependency chains.
Just tried installing in pbuilder:
[EMAIL PROTECTED]:/# apt-get install libmysqlclient15off
The following NE
On Fri, Jan 05, 2007 at 05:37:56PM +0100, Christoph Berg wrote:
> Hi,
>
> I'm packaging a database wrapper library (http://oss.devit.com/yada/).
> Its purpose is to provide one single API to a program and let the user
> configure if the database used is actually postgres/mysql/sqlite. The
> actual
On Fri, Jan 05, 2007 at 05:37:56PM +0100, Christoph Berg wrote:
> Hi,
>
> I'm packaging a database wrapper library (http://oss.devit.com/yada/).
> Its purpose is to provide one single API to a program and let the user
> configure if the database used is actually postgres/mysql/sqlite. The
> actual
On Fri, Jan 05, 2007 at 06:44:49PM +0100, Kurt Roeckx wrote:
> >From the subject, I seem to understand that those are added by shlibs?
> This seems to suggest that something in the package is linked to all the
> libraries, and I don't see how you could remove it.
The package contains plugins which
On Fri, Jan 05, 2007 at 06:44:49PM +0100, Kurt Roeckx wrote:
> If it's using dlopen(), you probably want to depend on the -dev packages,
> unless you want to hardcode the complete name of the library instead of
> the soname. It probably already breaks if they're not installed.
Of course soname is
Re: Kurt Roeckx 2007-01-05 <[EMAIL PROTECTED]>
> > | Depends: [...], libmysqlclient15off (>= 5.0.24-2), libpq4 (>= 8.1.4),
> > libsqlite3-0 (>= 3.3.8)
>
> >From the subject, I seem to understand that those are added by shlibs?
> This seems to suggest that something in the package is linked to all
Re: Mattia Dongili 2007-01-05 <[EMAIL PROTECTED]>
> > Is it in this case ok if I replace ',' by '|' there? This would allow
> > the user to really choose what database backend he wants.
>
> Yes, why not? does yada handles gracefully the absence of a library (eg.
> if incorrectly configured or such
On Friday, 5 January 2007 18:55, Christoph Berg wrote:
> It wouldn't change the fact that I'm formally breaking policy. (Or
> rather, the question *if* I would break it.)
I've exactly the same problem with the kexi plugins. For now I'm shipping
everything in the same package because there are only
Christoph Berg <[EMAIL PROTECTED]> wrote:
> I'm packaging a database wrapper library (http://oss.devit.com/yada/).
> Its purpose is to provide one single API to a program and let the user
> configure if the database used is actually postgres/mysql/sqlite. The
> actual interfacing with the databases
On Fri, Jan 05, 2007 at 07:33:56PM +0100, Andreas Metzler <[EMAIL PROTECTED]>
wrote:
> You could move the plugin's additional dependencies into Recommends,
> using "dpkg-shlibdeps -vRecommends" (...)
By the way, what is it supposed to happen in such a case ? What kind of
Recommends will dpkg-shli
Re: Andreas Metzler 2007-01-05 <[EMAIL PROTECTED]>
> Which does not seem to be properly translateable into a valid single
> fasel|(foo | bar, blah) Depends relation[1].
It won't work if a plugin needs more than one dependency, right.
> You could move the plugin's additional dependencies into Rec
On Fri, Jan 05, 2007 at 07:53:35PM +0100, Christoph Berg <[EMAIL PROTECTED]>
wrote:
> Re: Andreas Metzler 2007-01-05 <[EMAIL PROTECTED]>
> > Which does not seem to be properly translateable into a valid single
> > fasel|(foo | bar, blah) Depends relation[1].
>
> It won't work if a plugin needs m
Re: Mike Hommey 2007-01-05 <[EMAIL PROTECTED]>
> > Then remove the libc6 parts and use
^^
> > Depends: ${shlibs:Depends}, ${mysql:Depends} | ${postgres:Depends} |
> > ${sqlite:Depends}
... and make sure there's only one package left.
> Not exactly what you'd like...
On 2007-01-05 Mike Hommey <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 05, 2007 at 07:33:56PM +0100, Andreas Metzler <[EMAIL PROTECTED]>
> wrote:
> > You could move the plugin's additional dependencies into Recommends,
> > using "dpkg-shlibdeps -vRecommends" (...)
> By the way, what is it supposed to
On Fri, Jan 05, 2007 at 08:03:06PM +0100, Andreas Metzler <[EMAIL PROTECTED]>
wrote:
> On 2007-01-05 Mike Hommey <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 05, 2007 at 07:33:56PM +0100, Andreas Metzler <[EMAIL
> > PROTECTED]> wrote:
> > > You could move the plugin's additional dependencies into R
On Fri, Jan 05, 2007 at 06:44:49PM +0100, Kurt Roeckx wrote:
> If it's using dlopen(), you probably want to depend on the -dev packages,
> unless you want to hardcode the complete name of the library instead of
> the soname. It probably already breaks if they're not installed.
No, dlopen()ing an
> "Christoph" == Christoph Berg <[EMAIL PROTECTED]> writes:
Christoph> Is it in this case ok if I replace ',' by '|' there?
Christoph> This would allow the user to really choose what
Christoph> database backend he wants.
Use recommends instead of depends?
Split plugins into sepa
> "Mike" == Mike Hommey <[EMAIL PROTECTED]> writes:
>>
>> Then remove the libc6 parts and use Depends: ${shlibs:Depends},
>> ${mysql:Depends} | ${postgres:Depends} | ${sqlite:Depends}
Mike> Which may end up as libc6 (>= 2.3.5-1), libmysqlclient15off
Mike> (>= 5.0.24-2) | l
On Fri, Jan 05, 2007 at 05:37:56PM +0100, Christoph Berg wrote:
> I'm packaging a database wrapper library (http://oss.devit.com/yada/).
> Its purpose is to provide one single API to a program and let the user
> configure if the database used is actually postgres/mysql/sqlite. The
> actual interfac
Christoph Berg <[EMAIL PROTECTED]> writes:
> The alternative solution would be to put the plugins into separate
> packages and then depend on libyada-mysql | libyada-postgres |
> libyada-sqlite. As these packages would merely contain a single file,
> that seems bloat to me.
This is what I'd do.
Andreas Metzler <[EMAIL PROTECTED]> wrote:
[...]
> You could move the plugin's additional dependencies into Recommends,
> using "dpkg-shlibdeps -vRecommends"
[...]
-v is a typo, -d is the correct thing, e.g this
dpkg-shlibdeps /usr/bin/xine \
-dRecommends /usr/lib/xine/plugins/1.1.2/xineplug_decod
Re: Russ Allbery 2007-01-06 <[EMAIL PROTECTED]>
> This is what I'd do. Yes, it's a bunch of extra packages, but it clearly
> expresses the actual dependency structure, rather than an approximation of
> it, and that's usually a good thing in the long run.
As a very late follow up, here's what the
26 matches
Mail list logo
