> In general, you have a single source package (e.g. python-pythoncard) which
> builds/installs for each available Python version (and Build-Depends on the
> -dev version for each of those, obviously) into a python-pythoncard
> package, and an empty python-pythoncard package that Depends on the
> c
> > > This is getting a bit more complicated than I expected it to be. I'd
> > > appreciate any advice you can give me.
> > I don't know why you split docs and samples, I'd put them in one package,
> > the samples go into /usr/share/doc//examples/. The doc package
> > depending on either of the li
On Tue, Feb 04, 2003 at 10:59:17AM -0600, Kenneth Pronovici wrote:
> > > I've now noticed that this doesn't conform to policy and I'm a little
> > > confused about what packages I should provide.
> > Only the name of the module package is against policy - it should be
> > python-pythoncard.
> I'm
> > I've now noticed that this doesn't conform to policy and I'm a little
> > confused about what packages I should provide.
> Only the name of the module package is against policy - it should be
> python-pythoncard.
I'm going to take this to mean python2.2-pythoncard/python2.3-pythoncard
based o
tis 2003-02-04 klockan 12.46 skrev Bastian Kleineidam:
> > This is getting a bit more complicated than I expected it to be. I'd
> > appreciate any advice you can give me.
> I don't know why you split docs and samples, I'd put them in one package,
> the samples go into /usr/share/doc//examples/. Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 03, 2003 at 03:38:11PM -0600, Kenneth Pronovici wrote:
> I've now noticed that this doesn't conform to policy and I'm a little
> confused about what packages I should provide.
Only the name of the module package is against policy - it shou
6 matches
Mail list logo
