Shachar Shemesh wrote:
Benjamin Cutler wrote:
The debian/control file should look something like:
Package: foo-common
Conflicts: foo (<< 7.6.5-2)
Replaces: foo (<< 7.6.5-2)
Why the "Replaces"? I would have expected that would only be necessary if there
> was no longer any "foo" package.
The "R
On Wed, Apr 06, 2005 at 04:26:06PM +0530, Kapil Hari Paranjape wrote:
> Hello,
>
> I am currently the maintainer (non-DD) of tex4ht. This package consists of
> only two (!) compiled executables and a large number of Arch: all files.
>
> At least in etch I would like to split this package as sugge
Benjamin Cutler wrote:
The debian/control file should look something like:
Package: foo-common
Conflicts: foo (<< 7.6.5-2)
Replaces: foo (<< 7.6.5-2)
Why the "Replaces"? I would have expected that would only be necessary
if there was no longer any "foo" package.
Whether you use <= or << is mostly
Kapil Hari Paranjape wrote:
Hello,
I am currently the maintainer (non-DD) of tex4ht. This package consists of
only two (!) compiled executables and a large number of Arch: all files.
At least in etch I would like to split this package as suggested in best
packaging practice (Debian Ref). But that l
Hello,
I am currently the maintainer (non-DD) of tex4ht. This package consists of
only two (!) compiled executables and a large number of Arch: all files.
At least in etch I would like to split this package as suggested in best
packaging practice (Debian Ref). But that location gives hints about
On Fri, May 11, 2001 at 09:01:28AM -0700, Sean 'Shaleh' Perry wrote:
> >
> > If I did this, would I still have to move the hitop packages into
> > non-US (since it would still build-depend upon libpgsql-dev which is
> > now non-US)? Is there any way around this? Should I even care which
> > part o
On Fri, May 11, 2001 at 09:01:28AM -0700, Sean 'Shaleh' Perry wrote:
> >
> > If I did this, would I still have to move the hitop packages into
> > non-US (since it would still build-depend upon libpgsql-dev which is
> > now non-US)? Is there any way around this? Should I even care which
> > part
>
> If I did this, would I still have to move the hitop packages into
> non-US (since it would still build-depend upon libpgsql-dev which is
> now non-US)? Is there any way around this? Should I even care which
> part of the archive it goes in?
>
anything in non-us does not appear on the default
>
> If I did this, would I still have to move the hitop packages into
> non-US (since it would still build-depend upon libpgsql-dev which is
> now non-US)? Is there any way around this? Should I even care which
> part of the archive it goes in?
>
anything in non-us does not appear on the defaul
I was wondering about doing this for some time, but events have
forced my hand. hitop build-depends against libpgsql-dev which has
become main/non-US.
The situation as it stands is that 'hitop', a HTML preprocessor with
pretentions to be an web-based application server, is one package. It
is built
I was wondering about doing this for some time, but events have
forced my hand. hitop build-depends against libpgsql-dev which has
become main/non-US.
The situation as it stands is that 'hitop', a HTML preprocessor with
pretentions to be an web-based application server, is one package. It
is buil
On Mon, Mar 15, 1999 at 09:48:21AM -0500, Randolph Chung wrote:
> Another packaging question :)
>
> an upstream package contains both server and client programs. I'd like to
> split them up into a server package and a client package. how do you do this
> given one upstream source file? The client
Another packaging question :)
an upstream package contains both server and client programs. I'd like to
split them up into a server package and a client package. how do you do this
given one upstream source file? The client package is really just one file.
The reason to split it off is that the se
13 matches
Mail list logo
