Re: How to handle conffiles when renaming or splitting a package?

On 2021-01-03 09:02 +0900, Charles Plessy wrote: > I have recently split the mime-support package in two: media-types and > mailcap. But I wonder if I handled the conffiles correctly. > > mime-support had the conffiles `/etc/mime.types` and > `/etc/mailcap.order` until version 3.64. Version 3.65

How to handle conffiles when renaming or splitting a package?

Hello everybody, and happy new year ! I have recently split the mime-support package in two: media-types and mailcap. But I wonder if I handled the conffiles correctly. mime-support had the conffiles `/etc/mime.types` and `/etc/mailcap.order` until version 3.64. Version 3.65 is a transitional

Re: Splitting a package

On Sun, Jan 12, 2014 at 03:54:12PM +0100, Ol?? Streicher wrote: > Arno Töll writes: > > Please use Replaces in conjunction with Breaks (not Conflicts). See > > Policy §7.6.1 which explains your use case: > > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > > Thank you.

Re: Splitting a package

Arno Töll writes: > Hi Ole, > On 12.01.2014 13:30, Olе Streicher wrote: >> However, now I get a bug report that the >> new "-doc" package has files that would overwrite parts of the old base >> package. > Please use Replaces in conjunction with Breaks (not Conflict

Re: Splitting a package

Hi Ole, On 12.01.2014 13:30, Olе Streicher wrote: > However, now I get a bug report that the > new "-doc" package has files that would overwrite parts of the old base > package. > > How should I solve this problem? Should I set "Conflicts" and > "Replaces:" to "cpl

Splitting a package

Hi, to solve the problem of , split my package into an arch-dependent part (containing the binaries) and an arch-independent part (containing the manual pages and HTML documentation): cpl-plugin-fors (4.11.12+dfsg-1) --> cpl-plugin-fors + cpl-plugin-fors-doc (4.11.

Re: help creating a package (splitting a package and publishing it)

Hi, On Mon, Apr 18, 2011 at 8:17 PM, Reece Dunn wrote: > The project builds a shared library, two executables and provides > development API headers. At the moment, the output is all built into > one deb file. I want to break this up so that it complies with debian > packaging rules but I am not

help creating a package (splitting a package and publishing it)

Hi I am new to creating packages for Debian [1] and am in the process of creating a debian package for my project. - The project builds a shared library, two executables and provides development API headers. At the moment, the output is all built into one deb file. I want to break this up so

Re: Advice needed on splitting a package

Okay, so I've narrowed things down a bit, converted from CDBS to debhelper as per the general sentiment, and my progress can be seen in the python-modules repo[1]. Building the package results in the correct debs for the extensions (ie. anything with a .install file). But debhelper doesn't install

Advice needed on splitting a package

Hi, This was originally posted on the debian-python[0] list, but I haven't heard anything so I hope no-one minds if I repost my question here. I'd appreciate some advice (where to start, what docs to read, etc) on building separate binary packages for RabbitVCS. Previously we just separated the u

Re: advice about splitting a package (libtiff-tools)

I think I'll reply to my own post. I brought this up on IRC and was pointed to a better solution. > The libtiff package (upstream) includes one program, tiffgt, that > requires opengl. The current version of libtiff in debian installs > tiffgt's manual page but does not install tiffgt. (

Re: advice about splitting a package (libtiff-tools)

I think I'll reply to my own post. I brought this up on IRC and was pointed to a better solution. > The libtiff package (upstream) includes one program, tiffgt, that > requires opengl. The current version of libtiff in debian installs > tiffgt's manual page but does not install tiffgt. (

advice about splitting a package (libtiff-tools)

The libtiff package (upstream) includes one program, tiffgt, that requires opengl. The current version of libtiff in debian installs tiffgt's manual page but does not install tiffgt. (This is bug 219456.) I have built new libtiff packages that create tiffgt, which seems like a reasonable progra

advice about splitting a package (libtiff-tools)

The libtiff package (upstream) includes one program, tiffgt, that requires opengl. The current version of libtiff in debian installs tiffgt's manual page but does not install tiffgt. (This is bug 219456.) I have built new libtiff packages that create tiffgt, which seems like a reasonable progra

Re: splitting a package?

On Sun, Oct 19, 2003 at 03:26:40AM +0200, Magosányi Árpád wrote: > I have split up the zorp package to zorp, libzorp2 and zorp-pylib. > Also renamed zorp-dev to libzorp2-dev. > > Not uploaded it yet. > > Please advice me on this. I have some questions, but there may be > some issues that I did no

Re: splitting a package?

On Sun, Oct 19, 2003 at 03:26:40AM +0200, Magosányi Árpád wrote: > I have split up the zorp package to zorp, libzorp2 and zorp-pylib. > Also renamed zorp-dev to libzorp2-dev. > > Not uploaded it yet. > > Please advice me on this. I have some questions, but there may be > some issues that I did no

splitting a package?

Hi! I have split up the zorp package to zorp, libzorp2 and zorp-pylib. Also renamed zorp-dev to libzorp2-dev. Not uploaded it yet. Please advice me on this. I have some questions, but there may be some issues that I did not think of, and maybe common errors. Should I do something special when f

splitting a package?

Hi! I have split up the zorp package to zorp, libzorp2 and zorp-pylib. Also renamed zorp-dev to libzorp2-dev. Not uploaded it yet. Please advice me on this. I have some questions, but there may be some issues that I did not think of, and maybe common errors. Should I do something special when f

Splitting a package

I've been in some discussion with another developer. He's decided it would be nice to split out some interface modules for a package. These modules constitute reasonably small single files and copies of the relevant documentation. I'm of the opinion that a few KB is too small for a .deb that could

Re: Splitting a package

On Mon, Oct 13, 2003 at 04:51:12PM +0200, Alberto Gonzalez Iniesta wrote: > I'd like to know if this justifies splitting a package. AFAIK the > size or the existence of shared libs justify splitting a package, but > not this. > > I've got a package that contains a c

Splitting a package

I've been in some discussion with another developer. He's decided it would be nice to split out some interface modules for a package. These modules constitute reasonably small single files and copies of the relevant documentation. I'm of the opinion that a few KB is too small for a .deb that could

Re: Splitting a package

On Mon, Oct 13, 2003 at 04:51:12PM +0200, Alberto Gonzalez Iniesta wrote: > I'd like to know if this justifies splitting a package. AFAIK the > size or the existence of shared libs justify splitting a package, but > not this. > > I've got a package that contains a c

Re: Splitting a package

* Alberto Gonzalez Iniesta ([EMAIL PROTECTED]) [031013 17:24]: > I've got a package that contains a command line program and a couple of > front-ends (motif and KDE) for it. This makes neccessary to install > lots of KDE libs even if you're only using the command line program. > > Would all this

Re: Splitting a package

* Alberto Gonzalez Iniesta ([EMAIL PROTECTED]) [031013 17:24]: > I've got a package that contains a command line program and a couple of > front-ends (motif and KDE) for it. This makes neccessary to install > lots of KDE libs even if you're only using the command line program. > > Would all this

Re: Splitting a package

On Mon, Oct 13, 2003 at 04:51:12PM +0200, Alberto Gonzalez Iniesta wrote: > I'd like to know if this justifies splitting a package. AFAIK the > size or the existence of shared libs justify splitting a package, but > not this. > > I've got a package that contains a c

Splitting a package

Hi all, I'd like to know if this justifies splitting a package. AFAIK the size or the existence of shared libs justify splitting a package, but not this. I've got a package that contains a command line program and a couple of front-ends (motif and KDE) for it. This makes neccessary

Re: Splitting a package

On Mon, Oct 13, 2003 at 04:51:12PM +0200, Alberto Gonzalez Iniesta wrote: > I'd like to know if this justifies splitting a package. AFAIK the > size or the existence of shared libs justify splitting a package, but > not this. > > I've got a package that contains a c

Splitting a package

Hi all, I'd like to know if this justifies splitting a package. AFAIK the size or the existence of shared libs justify splitting a package, but not this. I've got a package that contains a command line program and a couple of front-ends (motif and KDE) for it. This makes neccessary

Re: splitting a package into several debs

On Fri, Nov 03, 2000 at 05:20:13PM +0100, Cesar Talon wrote: > I've been packaging it with the help of deb-make into one package, but now I > want to split it into several packages (maybe binary, libraries, devel and > docs+examples, or at least binary, devel and data) and would like to know what >

Re: splitting a package into several debs

On Fri, Nov 03, 2000 at 05:20:13PM +0100, Cesar Talon wrote: > I've been packaging it with the help of deb-make into one package, but now I > want to split it into several packages (maybe binary, libraries, devel and > docs+examples, or at least binary, devel and data) and would like to know what

Re: splitting a package into several debs

On Fri, Nov 03, 2000 at 06:17:50PM +0100, Josip Rodin wrote: > On Fri, Nov 03, 2000 at 05:59:20PM +0100, Cesar Talon wrote: > > I will do it with a smaller package, because guppi takes about 40 minutes > > tu build :( too much for testing purposes. > > While making the package, you don't have to u

Re: splitting a package into several debs

On 03-Nov-2000 Josip Rodin wrote: > On Fri, Nov 03, 2000 at 05:59:20PM +0100, Cesar Talon wrote: >> I will do it with a smaller package, because guppi takes about 40 minutes >> tu build :( too much for testing purposes. > > While making the package, you don't have to use dpkg-buildpackage all the

Re: splitting a package into several debs

On Fri, Nov 03, 2000 at 05:59:20PM +0100, Cesar Talon wrote: > I will do it with a smaller package, because guppi takes about 40 minutes > tu build :( too much for testing purposes. While making the package, you don't have to use dpkg-buildpackage all the time -- you can simulate most of it with `

Re: splitting a package into several debs

On Fri, Nov 03, 2000 at 06:17:50PM +0100, Josip Rodin wrote: > On Fri, Nov 03, 2000 at 05:59:20PM +0100, Cesar Talon wrote: > > I will do it with a smaller package, because guppi takes about 40 minutes > > tu build :( too much for testing purposes. > > While making the package, you don't have to

Re: splitting a package into several debs

On 03-Nov-2000 Christian T. Steigies wrote: >> I've been packaging it with the help of deb-make into one package, but now I >> want to split it into several packages (maybe binary, libraries, devel and >> docs+examples, or at least binary, devel and data) and would like to know >> what >> is the be

Re: splitting a package into several debs

Moin, On Fri, Nov 03, 2000 at 05:20:13PM +0100, Cesar Talon wrote: > Hi, > > First at all, this is my first mail here, so sorry if this isn't the best > place > to ask. This is absolutely the best and only place to ask questions like this! > The question is: > > I've been packaging it with the

splitting a package into several debs

Hi, First at all, this is my first mail here, so sorry if this isn't the best place to ask. I've been packaging guppi (www.gnome.org/guppi) for about one year now, but the project seems to be taking off now (soon to be an official extra-app for gnome 1.4). It is going to work as a component in gn

Re: splitting a package into several debs

On 03-Nov-2000 Josip Rodin wrote: > On Fri, Nov 03, 2000 at 05:59:20PM +0100, Cesar Talon wrote: >> I will do it with a smaller package, because guppi takes about 40 minutes >> tu build :( too much for testing purposes. > > While making the package, you don't have to use dpkg-buildpackage all the

Re: splitting a package into several debs

On Fri, Nov 03, 2000 at 05:59:20PM +0100, Cesar Talon wrote: > I will do it with a smaller package, because guppi takes about 40 minutes > tu build :( too much for testing purposes. While making the package, you don't have to use dpkg-buildpackage all the time -- you can simulate most of it with

Re: splitting a package into several debs

On 03-Nov-2000 Christian T. Steigies wrote: >> I've been packaging it with the help of deb-make into one package, but now I >> want to split it into several packages (maybe binary, libraries, devel and >> docs+examples, or at least binary, devel and data) and would like to know >> what >> is the b

Re: splitting a package into several debs

Moin, On Fri, Nov 03, 2000 at 05:20:13PM +0100, Cesar Talon wrote: > Hi, > > First at all, this is my first mail here, so sorry if this isn't the best place > to ask. This is absolutely the best and only place to ask questions like this! > The question is: > > I've been packaging it with the h

splitting a package into several debs

Hi, First at all, this is my first mail here, so sorry if this isn't the best place to ask. I've been packaging guppi (www.gnome.org/guppi) for about one year now, but the project seems to be taking off now (soon to be an official extra-app for gnome 1.4). It is going to work as a component in g

Splitting a package between doc and binary

Peter S Galbraith asks: > The gri package for i386 is 2MB in size. About 3/4 of that are > docs suitable for all archs. > > Should I split the package to save space on servers (sharing the > doc) and keep it as is to reduce name space and number of > packages? > > I do think most gri users will

Re: Splitting a package between doc and binary

> > The gri package for i386 is 2MB in size. About 3/4 of that are > docs suitable for all archs. > > Should I split the package to save space on servers (sharing the > doc) and keep it as is to reduce name space and number of > packages? > > I do think most gri users will want the docs (especi

Splitting a package between doc and binary

The gri package for i386 is 2MB in size. About 3/4 of that are docs suitable for all archs. Should I split the package to save space on servers (sharing the doc) and keep it as is to reduce name space and number of packages? I do think most gri users will want the docs (especially since it's a p