Re: Renaming a package
Quoting Santiago Vila <[EMAIL PROTECTED]>: > If the ordinary tools to upgrade the system are not enough to upgrade > the system and the release notes are longer than that, I think it's a > clear sign that we have made something wrong. I think versioned provides would be a way to fix this by avoiding the need for dummy packages. -- Jérôme Marant
Re: Renaming a package
Quoting Peter S Galbraith <[EMAIL PROTECTED]>: > I created a Packages.gz file to test the upgrade to these and added an > entry to it to sources.list. Here's what happens: > > # apt-get -u dist-upgrade > Reading Package Lists... Done > Building Dependency Tree... Done > Calculating Upgrade... Done > The following packages have been kept back > dpkg-dev-el emacs-goodies-el libsmpeg0 printtool rwho > The following packages will be upgraded > devscripts-el gnus-bonus-el > > So it's holding back the two affected packages. However, installing > them explicitely works: ... > > Am I missing something? I think Provides: doesn't act like Package: so APT doesn't understand that emacs-goodies-extra-el has to be replaced by emacs-goodies-el. Such a situation may change with (upcoming?) versioned provides. -- Jérôme Marant
Re: Renaming a package
Quoting Santiago Vila <[EMAIL PROTECTED]>: > If the ordinary tools to upgrade the system are not enough to upgrade > the system and the release notes are longer than that, I think it's a > clear sign that we have made something wrong. I think versioned provides would be a way to fix this by avoiding the need for dummy packages. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
Quoting Peter S Galbraith <[EMAIL PROTECTED]>: > I created a Packages.gz file to test the upgrade to these and added an > entry to it to sources.list. Here's what happens: > > # apt-get -u dist-upgrade > Reading Package Lists... Done > Building Dependency Tree... Done > Calculating Upgrade... Done > The following packages have been kept back > dpkg-dev-el emacs-goodies-el libsmpeg0 printtool rwho > The following packages will be upgraded > devscripts-el gnus-bonus-el > > So it's holding back the two affected packages. However, installing > them explicitely works: ... > > Am I missing something? I think Provides: doesn't act like Package: so APT doesn't understand that emacs-goodies-extra-el has to be replaced by emacs-goodies-el. Such a situation may change with (upcoming?) versioned provides. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xemacs specific .el
Quoting Sven Luther <[EMAIL PROTECTED]>: > Hello, Hello, > I have a package that installs a xemacs specific .el file, which > naturally don't build with the emacs20 package i have installed. > > Is there a way of specifying that only xemacs installs should build a > given .el or something such ? I'm going to have a look at this. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xemacs specific .el
Quoting Sven Luther <[EMAIL PROTECTED]>: > Hello, Hello, > I have a package that installs a xemacs specific .el file, which > naturally don't build with the emacs20 package i have installed. > > Is there a way of specifying that only xemacs installs should build a > given .el or something such ? I'm going to have a look at this. Cheers, -- Jérôme Marant
Re: GNAT 3.15p
Quoting Florian Weimer <[EMAIL PROTECTED]>: > Jérôme Marant <[EMAIL PROTECTED]> writes: > > > Please write to Florian Weimer first. He already did the job, so > > it's up to him to decide if he wants him packages to enter the > > archives rather than yours. > > I'm not a DD, so I have no word on this issue. But I'm going to have > a look at Ludovic' packages. > Neither is Ludovic. -- Jérôme Marant <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNAT 3.15p
Quoting Florian Weimer <[EMAIL PROTECTED]>: > Jérôme Marant <[EMAIL PROTECTED]> writes: > > > Please write to Florian Weimer first. He already did the job, so > > it's up to him to decide if he wants him packages to enter the > > archives rather than yours. > > I'm not a DD, so I have no word on this issue. But I'm going to have > a look at Ludovic' packages. > Neither is Ludovic. -- Jérôme Marant <[EMAIL PROTECTED]>
Re: GNAT 3.15p
Quoting Ludovic Brenta <[EMAIL PROTECTED]>: > > Folks, > > I have packaged gnat and gnat-doc 3.15p for Debian on i386, as well as > libgtkada2 (total, 3 source and 9 binary packages). They are > available for download here: Please write to Florian Weimer first. He already did the job, so it's up to him to decide if he wants him packages to enter the archives rather than yours. -- Jérôme Marant
Re: GNAT 3.15p
Quoting Ludovic Brenta <[EMAIL PROTECTED]>: > > Folks, > > I have packaged gnat and gnat-doc 3.15p for Debian on i386, as well as > libgtkada2 (total, 3 source and 9 binary packages). They are > available for download here: Please write to Florian Weimer first. He already did the job, so it's up to him to decide if he wants him packages to enter the archives rather than yours. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do you upload/build sponsored packages?
Andreas Metzler <[EMAIL PROTECTED]> writes: >> How is this possible? > > By following the instructions given in developers' reference instead > of the wrong ones given somewhere else. :-P I've not reread it lately. > Use use -k with debuild/dpkg-buildpackage instead of -m or > build without signing (debuild/dpkg-buildpackage -uc -us) and sign > afterwards with debsign. (Both debsign -m'My Name <[EMAIL PROTECTED]>' and > debsign -k are ok.) Thanks. -- Jérôme Marant http://marant.org
Re: How do you upload/build sponsored packages?
Colin Watson <[EMAIL PROTECTED]> writes: > On Thu, May 22, 2003 at 05:01:54PM +0200, J?r?me Marant wrote: >> When I sponsor a packages, I usually build it with : >> debuild -m'My Name <[EMAIL PROTECTED]>' >> >> But the .changes file looks like : >> Maintainer: My Name <[EMAIL PROTECTED]> >> Changed-By: Sponsoree <[EMAIL PROTECTED]> >> >> I can see several sponsored packages whose .changes file >> look like: >> Maintainer: Sponsoree <[EMAIL PROTECTED]> >> Changed-By: Sponsoree <[EMAIL PROTECTED]> >> >> How is this possible? > > Use 'debuild -k"your name"' instead (or, as I do, just use 'debuild -uc > -us' and run debsign afterwards when I've checked that the build looks > sane). Thanks. -- Jérôme Marant http://marant.org
How do you upload/build sponsored packages?
Hi, When I sponsor a packages, I usually build it with : debuild -m'My Name <[EMAIL PROTECTED]>' But the .changes file looks like : Maintainer: My Name <[EMAIL PROTECTED]> Changed-By: Sponsoree <[EMAIL PROTECTED]> I can see several sponsored packages whose .changes file look like: Maintainer: Sponsoree <[EMAIL PROTECTED]> Changed-By: Sponsoree <[EMAIL PROTECTED]> How is this possible? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: debian native and CVS
En réponse à Bill Allombert <[EMAIL PROTECTED]>: > Hello all, > > What is the best way to handle native Debian packages under CVS? > The problem is to avoid the CVS directories going in the tarball. Isn't "cvs export" what you need? -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: How to obtain current package version number?
En réponse à Sven Luther <[EMAIL PROTECTED]>: > On Tue, Mar 04, 2003 at 04:58:32PM +0100, Marc Haber wrote: > > On Tue, 4 Mar 2003 10:40:52 -0300, Henrique de Moraes Holschuh > > <[EMAIL PROTECTED]> wrote: > > >No. Do not skip the proper interface layers. Use dpkg to get that > > >information. > > > > Calling dpkg is actually the recommended way to do this? Can I call > > dpkg --list from a postinst script without having it explode? > > No, it is not. You just need to use the $1 argument to postinst, as > Jerome told you. IIRC, it is $2. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: How to obtain current package version number?
En réponse à Sven Luther <[EMAIL PROTECTED]>: > On Tue, Mar 04, 2003 at 04:58:32PM +0100, Marc Haber wrote: > > On Tue, 4 Mar 2003 10:40:52 -0300, Henrique de Moraes Holschuh > > <[EMAIL PROTECTED]> wrote: > > >No. Do not skip the proper interface layers. Use dpkg to get that > > >information. > > > > Calling dpkg is actually the recommended way to do this? Can I call > > dpkg --list from a postinst script without having it explode? > > No, it is not. You just need to use the $1 argument to postinst, as > Jerome told you. IIRC, it is $2. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to obtain current package version number?
En réponse à Marc Haber <[EMAIL PROTECTED]>: > Hi, Hi, > how can a package learn about its current version number? > > Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question > since /usr/share/doc need not be present, and calling dpkg --list > $PACKAGE and parsing its output looks like bad overkill. > > Does a maintainer script know the package version, so that it can > write the version number to a file? IIRC you can get it from the postinst parameters. You can have a look to the policy, in maintainers scripts section. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: How to obtain current package version number?
En réponse à Marc Haber <[EMAIL PROTECTED]>: > Hi, Hi, > how can a package learn about its current version number? > > Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question > since /usr/share/doc need not be present, and calling dpkg --list > $PACKAGE and parsing its output looks like bad overkill. > > Does a maintainer script know the package version, so that it can > write the version number to a file? IIRC you can get it from the postinst parameters. You can have a look to the policy, in maintainers scripts section. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate-conffile error ???
David Grant <[EMAIL PROTECTED]> writes: >>Debhelp automaticaly adds every /etc file to conffile. >>So, remove this entry from ocaml-base-3.06-1.conffiles. >> > I've been getting this error too. I just have a conffiles file in my > debian directory. It contains one /etc/ line. But if I > remove this line, what do I do instead? Add "install > /etc/" to the makefile? or the rules file? And then it > will automatically add this to the conffile? I think you misunderstood what I said :-) In other words, I said "Do nothing. Debhelper does it for you" :-) Remove conffile, and debhelper will feed a completely new one. Cheers, -- Jérôme Marant http://marant.org
Re: duplicate-conffile error ???
Sven Luther <[EMAIL PROTECTED]> writes: > Hello, ... > > I am preparing a new version of one of my packages, and lintian claims > that : > > $ lintian ocaml-base-3.06-1_3.06-16_i386.deb > E: ocaml-base-3.06-1: duplicate-conffile /etc/ocaml/ld.conf > > And effectively, if i open the .deb, i see that /etc/ocaml/ld.conf is > listed two times as conffile. > > Now, i have debian/ocaml-base-3.06-1.conffiles which contains only one > copy of /etc/ocaml/ld.conf, not two, so i have no idea where this second > copy does come from. > > I am using debhelper, and i guess one of the debhelpers is responsible > for this. Does anyone have an idea of where this is coming from ? Debhelp automaticaly adds every /etc file to conffile. So, remove this entry from ocaml-base-3.06-1.conffiles. Cheers, -- Jérôme Marant http://marant.org
Re: duplicate-conffile error ???
David Grant <[EMAIL PROTECTED]> writes: >>Debhelp automaticaly adds every /etc file to conffile. >>So, remove this entry from ocaml-base-3.06-1.conffiles. >> > I've been getting this error too. I just have a conffiles file in my > debian directory. It contains one /etc/ line. But if I > remove this line, what do I do instead? Add "install > /etc/" to the makefile? or the rules file? And then it > will automatically add this to the conffile? I think you misunderstood what I said :-) In other words, I said "Do nothing. Debhelper does it for you" :-) Remove conffile, and debhelper will feed a completely new one. Cheers, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate-conffile error ???
Sven Luther <[EMAIL PROTECTED]> writes: > Hello, ... > > I am preparing a new version of one of my packages, and lintian claims > that : > > $ lintian ocaml-base-3.06-1_3.06-16_i386.deb > E: ocaml-base-3.06-1: duplicate-conffile /etc/ocaml/ld.conf > > And effectively, if i open the .deb, i see that /etc/ocaml/ld.conf is > listed two times as conffile. > > Now, i have debian/ocaml-base-3.06-1.conffiles which contains only one > copy of /etc/ocaml/ld.conf, not two, so i have no idea where this second > copy does come from. > > I am using debhelper, and i guess one of the debhelpers is responsible > for this. Does anyone have an idea of where this is coming from ? Debhelp automaticaly adds every /etc file to conffile. So, remove this entry from ocaml-base-3.06-1.conffiles. Cheers, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting non-free packages built on all arches
En réponse à Sven Luther <[EMAIL PROTECTED]>: > On Thu, Feb 06, 2003 at 10:07:03PM +0100, Jérôme Marant wrote: > > > > Hi, > > > > Non-free packages don't seem to be autobuilt. > > Do I have to contact every autobuilder maintainer > > in order to get a non-free package built on every > > architecture? > > You could also log in one of the numerous debian machines, and build > it > yourself. Provided the dependencies are there, and even if not, you > only > need to ask debian-admin about it. I'm going to do so. > BTW, what package are you speaking about ? cxhextris that I orphaned months ago. Since it wasn't compiled on all arches, it is still listed as a package of mine in the w.d.o/devel/people page. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: Getting non-free packages built on all arches
En réponse à Sven Luther <[EMAIL PROTECTED]>: > On Thu, Feb 06, 2003 at 10:07:03PM +0100, Jérôme Marant wrote: > > > > Hi, > > > > Non-free packages don't seem to be autobuilt. > > Do I have to contact every autobuilder maintainer > > in order to get a non-free package built on every > > architecture? > > You could also log in one of the numerous debian machines, and build > it > yourself. Provided the dependencies are there, and even if not, you > only > need to ask debian-admin about it. I'm going to do so. > BTW, what package are you speaking about ? cxhextris that I orphaned months ago. Since it wasn't compiled on all arches, it is still listed as a package of mine in the w.d.o/devel/people page. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Getting non-free packages built on all arches
Hi, Non-free packages don't seem to be autobuilt. Do I have to contact every autobuilder maintainer in order to get a non-free package built on every architecture? Thanks. -- Jérôme Marant http://marant.org
Getting non-free packages built on all arches
Hi, Non-free packages don't seem to be autobuilt. Do I have to contact every autobuilder maintainer in order to get a non-free package built on every architecture? Thanks. -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to include a binary file
Karolina Lindqvist wrote: How do I include a binary file like a .png file in the diff? I need to include a PNG file with the application icon, which is not supplied in the upstreams tar. You have to include it uuencoded. Then, you uudecode it from debian/rules and install it in its proper location. Don't forget to add sharutils to Build-Depends. Cheers,
Re: How to include a binary file
Karolina Lindqvist wrote: How do I include a binary file like a .png file in the diff? I need to include a PNG file with the application icon, which is not supplied in the upstreams tar. You have to include it uuencoded. Then, you uudecode it from debian/rules and install it in its proper location. Don't forget to add sharutils to Build-Depends. Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FYI: GNAT 3.15p has been released
Jon Ward wrote: On Sun, Nov 24, 2002 at 08:47:35PM +0100, J?r?me Marant wrote: This is just a reminder that GNAT 3.15p has been released. I think that it is far more stable that the version from GCC so it would be nice to make it available to Ada coders. I recall that some people were interested in taking it over. I've been working on it this weekend - I've retitled the bugs for gnat and gnat-doc to ITA. As I type, my old SparcStation 4 is chugging away with a compile of it. Good! Bear with me, these are my first Debian packages... Sponsors will check the packages anyway. Cheers,
Re: FYI: GNAT 3.15p has been released
Jon Ward wrote: On Sun, Nov 24, 2002 at 08:47:35PM +0100, J?r?me Marant wrote: This is just a reminder that GNAT 3.15p has been released. I think that it is far more stable that the version from GCC so it would be nice to make it available to Ada coders. I recall that some people were interested in taking it over. I've been working on it this weekend - I've retitled the bugs for gnat and gnat-doc to ITA. As I type, my old SparcStation 4 is chugging away with a compile of it. Good! Bear with me, these are my first Debian packages... Sponsors will check the packages anyway. Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FYI: GNAT 3.15p has been released
Hi, This is just a reminder that GNAT 3.15p has been released. I think that it is far more stable that the version from GCC so it would be nice to make it available to Ada coders. I recall that some people were interested in taking it over. Cheers, -- Jérôme Marant http://marant.org
FYI: GNAT 3.15p has been released
Hi, This is just a reminder that GNAT 3.15p has been released. I think that it is far more stable that the version from GCC so it would be nice to make it available to Ada coders. I recall that some people were interested in taking it over. Cheers, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNAT
[Please no CC on reply, I'm subscribed to the list] Florian Weimer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Jérôme Marant) writes: > >> What about ACT not fixing bugs in the GNAT public releases? > > They do fix them, but they have extremely long release cycles. Would it be that hard for them to send patches? >> What about them not caring at all for bugs reported in the >> BTS and not sending any patch? > > Only two of the bug reports have been forwarded to them, so you can't > really blame ACT. And for one of those forwarded bug reports, I > remember reading public comments by ACT. Currently, only ACT customers will get bugfixes in a reasonnable time frame. So, bug reports help their customers rather than those who reported them, unfortunately. This is why I'm saying that this is not a proper cooperation with the community. >> The next GNAT maintainer must be warned that ACT does not >> cooperate very nicely with the community and it is still the case >> of the GNAT in the GCC tree. > > ACT is quite helpful even if you haven't got a support contract, but > they do not accept proxies, i.e. they expect Debian users to contact > them directly. Yes, but again, they won't send patches. -- Jérôme Marant http://marant.org
Re: GNAT
[Please no CC on reply, I'm subscribed to the list] Florian Weimer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Jérôme Marant) writes: > >> What about ACT not fixing bugs in the GNAT public releases? > > They do fix them, but they have extremely long release cycles. Would it be that hard for them to send patches? >> What about them not caring at all for bugs reported in the >> BTS and not sending any patch? > > Only two of the bug reports have been forwarded to them, so you can't > really blame ACT. And for one of those forwarded bug reports, I > remember reading public comments by ACT. Currently, only ACT customers will get bugfixes in a reasonnable time frame. So, bug reports help their customers rather than those who reported them, unfortunately. This is why I'm saying that this is not a proper cooperation with the community. >> The next GNAT maintainer must be warned that ACT does not >> cooperate very nicely with the community and it is still the case >> of the GNAT in the GCC tree. > > ACT is quite helpful even if you haven't got a support contract, but > they do not accept proxies, i.e. they expect Debian users to contact > them directly. Yes, but again, they won't send patches. -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNAT
Florian Weimer <[EMAIL PROTECTED]> writes: > Jon Ward <[EMAIL PROTECTED]> writes: > >> I would like to adopt the gnat package. > > What about gnat-doc? There are a number of problems with it (non-free > license, wrong copyright information in general, the RM should be > separate). What about ACT not fixing bugs in the GNAT public releases? What about them not caring at all for bugs reported in the BTS and not sending any patch? The next GNAT maintainer must be warned that ACT does not cooperate very nicely with the community and it is still the case of the GNAT in the GCC tree. (Prove me wrong) Cheers, -- Jérôme Marant http://marant.org
Re: GNAT
Florian Weimer <[EMAIL PROTECTED]> writes: > Jon Ward <[EMAIL PROTECTED]> writes: > >> I would like to adopt the gnat package. > > What about gnat-doc? There are a number of problems with it (non-free > license, wrong copyright information in general, the RM should be > separate). What about ACT not fixing bugs in the GNAT public releases? What about them not caring at all for bugs reported in the BTS and not sending any patch? The next GNAT maintainer must be warned that ACT does not cooperate very nicely with the community and it is still the case of the GNAT in the GCC tree. (Prove me wrong) Cheers, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
En réponse à Joey Hess <[EMAIL PROTECTED]>: > Sven LUTHER wrote: > > Since the bytecode executables are arch independent, i think it would > be > > nice to build them arch: all, since this would mean, apart from > smaller > > sized packages, also that we don't have 12+ version of the same thing > in > > the archive (well, at least we can spare all the arches which do not > > support native code compilers). > > > > But then, on arches supporting the native code compiler, we want to > > build the app as native code, since this will result in faster > > executables. > > Well if I were you I would avoid the route of splitting off a bunch of > -bytecode and -native packages and simply make it arch any and build > natice packages on arches where I could, and bytecode packages > elsewhere. It uses up a bit of archive space, but is no worse than any > compiled program. Trying to save a snidgeon of archive space just > because you can here is a kind of false optimization, as you are > introducing a lot of unnecessary complexity, both for yourself and for > the user in the process of doing so. If these packages are 20 or 100 > mb > in size, it might be worth trying to optimize for space, but if they > are > fairly normal in size, it's probably more important to package them in > a > comprehensible and simple manner. This is exactly what I think. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: packages which can be arch: all and arch: any ...
En réponse à Joey Hess <[EMAIL PROTECTED]>: > Sven LUTHER wrote: > > Since the bytecode executables are arch independent, i think it would > be > > nice to build them arch: all, since this would mean, apart from > smaller > > sized packages, also that we don't have 12+ version of the same thing > in > > the archive (well, at least we can spare all the arches which do not > > support native code compilers). > > > > But then, on arches supporting the native code compiler, we want to > > build the app as native code, since this will result in faster > > executables. > > Well if I were you I would avoid the route of splitting off a bunch of > -bytecode and -native packages and simply make it arch any and build > natice packages on arches where I could, and bytecode packages > elsewhere. It uses up a bit of archive space, but is no worse than any > compiled program. Trying to save a snidgeon of archive space just > because you can here is a kind of false optimization, as you are > introducing a lot of unnecessary complexity, both for yourself and for > the user in the process of doing so. If these packages are 20 or 100 > mb > in size, it might be worth trying to optimize for space, but if they > are > fairly normal in size, it's probably more important to package them in > a > comprehensible and simple manner. This is exactly what I think. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python scrips and deps
On Thu, Sep 26, 2002 at 01:08:00PM +0100, Ross Burton wrote: > On Thu, 2002-09-26 at 13:04, Colin Watson wrote: > > On Thu, Sep 26, 2002 at 12:38:08PM +0100, Ross Burton wrote: > > > I am the maintainer for doclifter, a Python 2.2 script. Upstream (RMS) > > > > ESR surely? > > Yes... whoops. Wrong uber-geek :) Let's see who's gonna feel offended by the confusion ;-) -- Jérôme Marant
Re: Python scrips and deps
On Thu, Sep 26, 2002 at 01:47:35PM +0200, Bastian Kleineidam wrote: > On Thu, Sep 26, 2002 at 12:38:08PM +0100, Ross Burton wrote: > > I am the maintainer for doclifter, a Python 2.2 script. Upstream (RMS) > > claims that it requires Python 2.2, so the script calls "/usr/bin/env > > python2.2" and the package Requires: python2.2. > > > > However, lintian now moans as "python2.2" isn't a valid Python > > interpreter. I'd say this is a bug (and I intend to report it in a > > minute) but this does bring up an interesting issue. > You should not use the env trick. Use #!/usr/bin/python2.2 for python2.2 > scripts and #!/usr/bin/python for python scripts. Why shouldn't env be used? > > The default Python release in Debian Sid (and testing?) is now 2.2, so > > should I change the package to call "python" and change the requirements > > to Depends: python? > It is always good to support the default python version. You must have > Depends: python (>=2.2), python (<<2.3) But I guess that if upstream absolutely want to use a specific Python, there isn't any reason not to leave Depends: python2.2. I don't see any problem here. Cheers, -- Jérôme Marant
Re: Python scrips and deps
On Thu, Sep 26, 2002 at 01:08:00PM +0100, Ross Burton wrote: > On Thu, 2002-09-26 at 13:04, Colin Watson wrote: > > On Thu, Sep 26, 2002 at 12:38:08PM +0100, Ross Burton wrote: > > > I am the maintainer for doclifter, a Python 2.2 script. Upstream (RMS) > > > > ESR surely? > > Yes... whoops. Wrong uber-geek :) Let's see who's gonna feel offended by the confusion ;-) -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python scrips and deps
On Thu, Sep 26, 2002 at 01:47:35PM +0200, Bastian Kleineidam wrote: > On Thu, Sep 26, 2002 at 12:38:08PM +0100, Ross Burton wrote: > > I am the maintainer for doclifter, a Python 2.2 script. Upstream (RMS) > > claims that it requires Python 2.2, so the script calls "/usr/bin/env > > python2.2" and the package Requires: python2.2. > > > > However, lintian now moans as "python2.2" isn't a valid Python > > interpreter. I'd say this is a bug (and I intend to report it in a > > minute) but this does bring up an interesting issue. > You should not use the env trick. Use #!/usr/bin/python2.2 for python2.2 > scripts and #!/usr/bin/python for python scripts. Why shouldn't env be used? > > The default Python release in Debian Sid (and testing?) is now 2.2, so > > should I change the package to call "python" and change the requirements > > to Depends: python? > It is always good to support the default python version. You must have > Depends: python (>=2.2), python (<<2.3) But I guess that if upstream absolutely want to use a specific Python, there isn't any reason not to leave Depends: python2.2. I don't see any problem here. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg's treatment of symlinks
On Mon, Sep 23, 2002 at 02:45:41PM -0700, Ian Zimmerman wrote: > > Marco> I found out a little more about my current troubles with the > Marco> new versions of my packages mozart, mozart-contrib, and > Marco> mozart-doc-html. The phenomenon is this: > > Jérôme> The answer is there: > > Jérôme> > http://lists.debian.org/debian-devel/2001/debian-devel-200107/msg01666.html > > Marco> 2. What do I have to do in order to prevent it from doing it? > > Jérôme> See icewm package (maintainer scripts). > > I have read the thread mentioned above by Jérôme before, and I think I > understand the reason why dpkg behaves this way. At that moment, I had to insist a lot to get explainations. > But there remains the 'no return' part of Jérôme's post which started > the thread. Does this mean the maintainer is stuck with a postinst > hack forever? How is a transition to a symlink shipped as part of the > package possible in a future version? I don't know about the dpkg internals. But in my opinion, dpkg could try to check if the symlink or directory is shared among several packages and do the replacement iff only one package owns such files. However, I don't know if such checkings are enough to be safe. -- Jérôme Marant
Re: dpkg's treatment of symlinks
On Mon, Sep 23, 2002 at 02:45:41PM -0700, Ian Zimmerman wrote: > > Marco> I found out a little more about my current troubles with the > Marco> new versions of my packages mozart, mozart-contrib, and > Marco> mozart-doc-html. The phenomenon is this: > > Jérôme> The answer is there: > > Jérôme> http://lists.debian.org/debian-devel/2001/debian-devel-200107/msg01666.html > > Marco> 2. What do I have to do in order to prevent it from doing it? > > Jérôme> See icewm package (maintainer scripts). > > I have read the thread mentioned above by Jérôme before, and I think I > understand the reason why dpkg behaves this way. At that moment, I had to insist a lot to get explainations. > But there remains the 'no return' part of Jérôme's post which started > the thread. Does this mean the maintainer is stuck with a postinst > hack forever? How is a transition to a symlink shipped as part of the > package possible in a future version? I don't know about the dpkg internals. But in my opinion, dpkg could try to check if the symlink or directory is shared among several packages and do the replacement iff only one package owns such files. However, I don't know if such checkings are enough to be safe. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg's treatment of symlinks
Marco Kuhlmann <[EMAIL PROTECTED]> writes: > Dear mentors, Hi, > I found out a little more about my current troubles with the new > versions of my packages mozart, mozart-contrib, and > mozart-doc-html. The phenomenon is this: > > Where the old version of mozart contains a _directory_ > /usr/lib/mozart/include and a _symlink_ to it from > /usr/include/mozart, the new version has a _symlink_ > /usr/lib/mozart/include and a _directory_ /usr/include/mozart. > After updating from 1.2.3 to 1.2.4, /usr/lib/mozart/include is a > directory that still contains all the files that were present in > the old version (although it should be a symlink), and > /usr/include/mozart is a symlink to /usr/lib/mozart/include, as > in the old version. > > Two questions: > > 1. Why is dpkg doing this? (Should it do this? Is > this related to bug #156463?), and, more pragmatically, The answer is there: http://lists.debian.org/debian-devel/2001/debian-devel-200107/msg01666.html > 2. What do I have to do in order to prevent it from doing it? See icewm package (maintainer scripts). Cheers, -- Jérôme Marant http://marant.org
Re: dpkg's treatment of symlinks
Marco Kuhlmann <[EMAIL PROTECTED]> writes: > Dear mentors, Hi, > I found out a little more about my current troubles with the new > versions of my packages mozart, mozart-contrib, and > mozart-doc-html. The phenomenon is this: > > Where the old version of mozart contains a _directory_ > /usr/lib/mozart/include and a _symlink_ to it from > /usr/include/mozart, the new version has a _symlink_ > /usr/lib/mozart/include and a _directory_ /usr/include/mozart. > After updating from 1.2.3 to 1.2.4, /usr/lib/mozart/include is a > directory that still contains all the files that were present in > the old version (although it should be a symlink), and > /usr/include/mozart is a symlink to /usr/lib/mozart/include, as > in the old version. > > Two questions: > > 1. Why is dpkg doing this? (Should it do this? Is > this related to bug #156463?), and, more pragmatically, The answer is there: http://lists.debian.org/debian-devel/2001/debian-devel-200107/msg01666.html > 2. What do I have to do in order to prevent it from doing it? See icewm package (maintainer scripts). Cheers, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mldonkey needs sponsor
> Jérôme Marant wrote: >> Goswin, why didn't you get any clue? Did you read the thread in >> the WNPP RFP bug? Did you read mldonkey-archives? I think you >> didn't. > > Before getting offensive read the mldonkey-mailing lists yourself. Goswin, Please accept my apologies for being offensive in debian-mentors. I had indeed myself no clue about this recent changes, although I'm often in touch with mldonkey authors on the OCaml front. Sincerely, -- Jérôme Marant http://marant.org
Re: mldonkey needs sponsor
> Jérôme Marant wrote: >> Goswin, why didn't you get any clue? Did you read the thread in >> the WNPP RFP bug? Did you read mldonkey-archives? I think you >> didn't. > > Before getting offensive read the mldonkey-mailing lists yourself. Goswin, Please accept my apologies for being offensive in debian-mentors. I had indeed myself no clue about this recent changes, although I'm often in touch with mldonkey authors on the OCaml front. Sincerely, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mldonkey needs sponsor
On Thu, Sep 05, 2002 at 01:07:36PM +0200, Guillaume Morin wrote: > Dans un message du 05 Sep à 13:02, Goswin Brederlow écrivait : > > No, 100% GPL due to emule being GPL already makeing it pointless to > > hide the core protocl. > > There have been some discussions in the savannah mailing lists about two > binary files in the distribution. Can you confirm that this issue is > solved ? It has been solved on the Savannah side: the binary files have been removed from the CVS. Now, the Makefile download the binaries from some location and the application is built upon it. So the application should definitely go to non-free or the edonkey support should be removed. Goswin, why didn't you get any clue? Did you read the thread in the WNPP RFP bug? Did you read mldonkey-archives? I think you didn't. -- Jérôme Marant
Re: mldonkey needs sponsor
On Thu, Sep 05, 2002 at 11:56:13AM +0200, Goswin Brederlow wrote: > Hi, > > I _started_ packaging mldonkey and have some preliminary deb packages > at > > rsync rsync://mrvn.homeip.net/mldonkey > > If anyone here is intrested in testing and sponsoring mldonkey let me > know. Also feel free to take a look at the package, good comments are > allways appreciated. It is going to non-free right ? -- Jérôme Marant
Re: mldonkey needs sponsor
On Thu, Sep 05, 2002 at 01:07:36PM +0200, Guillaume Morin wrote: > Dans un message du 05 Sep à 13:02, Goswin Brederlow écrivait : > > No, 100% GPL due to emule being GPL already makeing it pointless to > > hide the core protocl. > > There have been some discussions in the savannah mailing lists about two > binary files in the distribution. Can you confirm that this issue is > solved ? It has been solved on the Savannah side: the binary files have been removed from the CVS. Now, the Makefile download the binaries from some location and the application is built upon it. So the application should definitely go to non-free or the edonkey support should be removed. Goswin, why didn't you get any clue? Did you read the thread in the WNPP RFP bug? Did you read mldonkey-archives? I think you didn't. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mldonkey needs sponsor
On Thu, Sep 05, 2002 at 11:56:13AM +0200, Goswin Brederlow wrote: > Hi, > > I _started_ packaging mldonkey and have some preliminary deb packages > at > > rsync rsync://mrvn.homeip.net/mldonkey > > If anyone here is intrested in testing and sponsoring mldonkey let me > know. Also feel free to take a look at the package, good comments are > allways appreciated. It is going to non-free right ? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chained dependencies handling in debian/control
On Mon, Sep 02, 2002 at 01:46:53PM +0200, Alexandre wrote: > Hello, > > Let package A depend on package B and C. > Let package B depend on package C. > I maintain A, someone else maintains B and C. > > Should I explicitely let A depend on B and C in debian/control, or is it > OK -- or better -- to let it depend only on B? > > In the case at hand: > A = python2.1-xml > B = python2.1-xmlbase > C = python2.1 Yes, you must specify them explicitely, because there is no transitivity in the package system. You must think of B and C as independant packages need by A. Cheers, -- Jérôme Marant
Re: chained dependencies handling in debian/control
On Mon, Sep 02, 2002 at 01:46:53PM +0200, Alexandre wrote: > Hello, > > Let package A depend on package B and C. > Let package B depend on package C. > I maintain A, someone else maintains B and C. > > Should I explicitely let A depend on B and C in debian/control, or is it > OK -- or better -- to let it depend only on B? > > In the case at hand: > A = python2.1-xml > B = python2.1-xmlbase > C = python2.1 Yes, you must specify them explicitely, because there is no transitivity in the package system. You must think of B and C as independant packages need by A. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
On Thu, Aug 29, 2002 at 03:21:11PM +0200, Tollef Fog Heen wrote: > * Jérôme Marant > > | On Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen wrote: > | > | > So, even though you might know stuff about sponsorship, you do not own > | > the term. What I (and it seems a lot of other people) think is that > | > the current system works fine. At least, it works a lot better than > | > having to handle it through the BTS. IMO. > | > | No, from my point of view it is not enough. I have no way to > | keep track of the sponsorship work. > > Then I suggest you scratch your itch without forcing everybody else to > have the same itch as you. I want something that you don't need. Then, I win. 'Tell me what you need and I'll tell you how not to need it' That's what you are proposing. If you don't need anything, how about tolerating that some people need something? > | I have a recent case of someone who NMU'ed packages of someone > | I do sponsor but I wasn't aware of that. > > Then you hadn't subscribed to the package through the PTS, I think. Of course I did, but NMU requests have never been implied access to the BTS. I want an entry point for contacts with the sponsoree. I don't have any currently. > What I understand buxy wants the BTS for is for making sure people are > able to find a sponsor, and a way to see which sponsorees who don't > have a sponsor. Not do all the sponsor/sponsoree comms through the > BTS. It is a matter of practice. The one Raphaël is proposing would not be annoying at all. -- Jérôme Marant
Re: Use of the BTS for managing sponsorship
On Thu, Aug 29, 2002 at 01:49:29PM +0100, Mark Brown wrote: > On Thu, Aug 29, 2002 at 02:11:20PM +0200, Jérôme Marant wrote: > > > I have a recent case of someone who NMU'ed packages of someone > > I do sponsor but I wasn't aware of that. > > For things like that the PTS is probably the way to go. The PTS works with the BTS. > > I would like an entry point for communicating with the sponsoree > > so I can get informed about such events. > > Remember that with a BTS based solution the e-mails aren't going to miss > either you or the person being sponsored by default and there's no > particular reason why anyone is going to know that the package has been > sponsored. If the maintainer is not registered in the developer's database, the package has surely been sponsored. -- Jérôme Marant
Re: Use of the BTS for managing sponsorship
On Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen wrote: > * Raphael Hertzog > > | I'm the guy who invented sponsorship, I'm the one who wrote the > | sponsorhip CGI. > > Most of my sponsorees haven't come from the CGI of yours, but from > this list, or #debian-devel. > > So, even though you might know stuff about sponsorship, you do not own > the term. What I (and it seems a lot of other people) think is that > the current system works fine. At least, it works a lot better than > having to handle it through the BTS. IMO. No, from my point of view it is not enough. I have no way to keep track of the sponsorship work. I have a recent case of someone who NMU'ed packages of someone I do sponsor but I wasn't aware of that. I would like an entry point for communicating with the sponsoree so I can get informed about such events. The BTS plus the PTS provide what I need currently. So, I want the sponsorship managed through the BTS. -- Jérôme Marant
Re: Use of the BTS for managing sponsorship
On Thu, Aug 29, 2002 at 03:21:11PM +0200, Tollef Fog Heen wrote: > * Jérôme Marant > > | On Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen wrote: > | > | > So, even though you might know stuff about sponsorship, you do not own > | > the term. What I (and it seems a lot of other people) think is that > | > the current system works fine. At least, it works a lot better than > | > having to handle it through the BTS. IMO. > | > | No, from my point of view it is not enough. I have no way to > | keep track of the sponsorship work. > > Then I suggest you scratch your itch without forcing everybody else to > have the same itch as you. I want something that you don't need. Then, I win. 'Tell me what you need and I'll tell you how not to need it' That's what you are proposing. If you don't need anything, how about tolerating that some people need something? > | I have a recent case of someone who NMU'ed packages of someone > | I do sponsor but I wasn't aware of that. > > Then you hadn't subscribed to the package through the PTS, I think. Of course I did, but NMU requests have never been implied access to the BTS. I want an entry point for contacts with the sponsoree. I don't have any currently. > What I understand buxy wants the BTS for is for making sure people are > able to find a sponsor, and a way to see which sponsorees who don't > have a sponsor. Not do all the sponsor/sponsoree comms through the > BTS. It is a matter of practice. The one Raphaël is proposing would not be annoying at all. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
On Thu, Aug 29, 2002 at 01:49:29PM +0100, Mark Brown wrote: > On Thu, Aug 29, 2002 at 02:11:20PM +0200, Jérôme Marant wrote: > > > I have a recent case of someone who NMU'ed packages of someone > > I do sponsor but I wasn't aware of that. > > For things like that the PTS is probably the way to go. The PTS works with the BTS. > > I would like an entry point for communicating with the sponsoree > > so I can get informed about such events. > > Remember that with a BTS based solution the e-mails aren't going to miss > either you or the person being sponsored by default and there's no > particular reason why anyone is going to know that the package has been > sponsored. If the maintainer is not registered in the developer's database, the package has surely been sponsored. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
On Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen wrote: > * Raphael Hertzog > > | I'm the guy who invented sponsorship, I'm the one who wrote the > | sponsorhip CGI. > > Most of my sponsorees haven't come from the CGI of yours, but from > this list, or #debian-devel. > > So, even though you might know stuff about sponsorship, you do not own > the term. What I (and it seems a lot of other people) think is that > the current system works fine. At least, it works a lot better than > having to handle it through the BTS. IMO. No, from my point of view it is not enough. I have no way to keep track of the sponsorship work. I have a recent case of someone who NMU'ed packages of someone I do sponsor but I wasn't aware of that. I would like an entry point for communicating with the sponsoree so I can get informed about such events. The BTS plus the PTS provide what I need currently. So, I want the sponsorship managed through the BTS. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to make a package version different from the source version?
Hi, I would like to split a single source tarball that contains multiple components which have their own version. These versions are different from the main tarball version. It looks like the python-gnome package does this, but I cannot see exactly how it works. How can I perform this? Thanks in advance. -- Jérôme Marant
How to make a package version different from the source version?
Hi, I would like to split a single source tarball that contains multiple components which have their own version. These versions are different from the main tarball version. It looks like the python-gnome package does this, but I cannot see exactly how it works. How can I perform this? Thanks in advance. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf questions and purge
Raphael Hertzog <[EMAIL PROTECTED]> writes: > Le Fri, Aug 02, 2002 at 12:23:07PM -0400, Joey Hess écrivait: >> > A same kind of problem is likely to happen for the conffiles and other >> > non-conffiles configuration files that I move from wwsympa to sympa >> > and that are been removed in wwsympa postrm. >> >> I'm afraid you're on your own there; dpkg does not deal with shared >> conffiles well when the older package is removed I think it removes the >> conffile. > > I'm not sure but if sympa has the "Replaces: wwsympa" then the file > should be owned by sympa and not wwsympa, so when purging wwsympa, the > configuration file should be kept. > > Of course, if wwsympa is purged before installing sympa, then you lost > the file. And if you add a conflict, then wwsympa will be simply > removed (and not purged) by apt ... On automatic upgrade, there won't be any problem because dpkg is used with the remove option. I only have to hope that the user will never purge the package. -- Jérôme Marant http://marant.org
Re: Debconf questions and purge
Raphael Hertzog <[EMAIL PROTECTED]> writes: > Le Fri, Aug 02, 2002 at 12:23:07PM -0400, Joey Hess écrivait: >> > A same kind of problem is likely to happen for the conffiles and other >> > non-conffiles configuration files that I move from wwsympa to sympa >> > and that are been removed in wwsympa postrm. >> >> I'm afraid you're on your own there; dpkg does not deal with shared >> conffiles well when the older package is removed I think it removes the >> conffile. > > I'm not sure but if sympa has the "Replaces: wwsympa" then the file > should be owned by sympa and not wwsympa, so when purging wwsympa, the > configuration file should be kept. > > Of course, if wwsympa is purged before installing sympa, then you lost > the file. And if you add a conflict, then wwsympa will be simply > removed (and not purged) by apt ... On automatic upgrade, there won't be any problem because dpkg is used with the remove option. I only have to hope that the user will never purge the package. -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf questions and purge
Joey Hess <[EMAIL PROTECTED]> writes: > Jérôme Marant wrote: >> I need to merge the wwsympa package into sympa. Both packages >> use debconf. >> I wonder how I should merge wwsympa debconf templates into sympa's. >> In sympa, debconf variables start with sympa/ and wwsympa ones >> start with wwsympa/ >> If I keep the same variable name, I feel like I'm going to have >> problem if the user decide to purge wwsympa, because of db_purge. >> So do I really have to care for the purge and to rename variables? > > Well, you basically have two options: > > 1. Don't change the name. Put identically named wsympa/* templates into >sympa and watch debconf do the right thing. (That is, when the new >sympa is installed, it will mark the templates as shared between the >two packages that contain them; then when wsympa is purged it will >remove it from the owners list of the questions but keep them around >since one other package still owns them. Reference counting.) Smart ;-) I love this. You've made my day! >> A same kind of problem is likely to happen for the conffiles and other >> non-conffiles configuration files that I move from wwsympa to sympa >> and that are been removed in wwsympa postrm. > > I'm afraid you're on your own there; dpkg does not deal with shared > conffiles well when the older package is removed I think it removes the > conffile. I see no real solution to this. One disgusting way for non-conffiles would be to delete the removing part: if [ -e /var/lib/dpkg/info/wwsympa.postrm ]; then sed fi I think you won't like this, will you? ;-) -- Jérôme Marant http://marant.org
Re: Debconf questions and purge
Ian Zimmerman <[EMAIL PROTECTED]> writes: > Jerome> A same kind of problem is likely to happen for the conffiles > Jerome> and other non-conffiles configuration files that I move from > Jerome> wwsympa to sympa and that are been removed in wwsympa postrm. > > Joey> I'm afraid you're on your own there; dpkg does not deal with > Joey> shared conffiles well when the older package is removed I think > Joey> it removes the conffile. > > Surely you mean "when the older package is _purged_"? Yes, purged. > I have done "dpkg --remove oldname ; apt-get install newname" many > times on my system, and I think it works. It is ok with remove. -- Jérôme Marant http://marant.org
Re: Debconf questions and purge
Joey Hess <[EMAIL PROTECTED]> writes: > Jérôme Marant wrote: >> I need to merge the wwsympa package into sympa. Both packages >> use debconf. >> I wonder how I should merge wwsympa debconf templates into sympa's. >> In sympa, debconf variables start with sympa/ and wwsympa ones >> start with wwsympa/ >> If I keep the same variable name, I feel like I'm going to have >> problem if the user decide to purge wwsympa, because of db_purge. >> So do I really have to care for the purge and to rename variables? > > Well, you basically have two options: > > 1. Don't change the name. Put identically named wsympa/* templates into >sympa and watch debconf do the right thing. (That is, when the new >sympa is installed, it will mark the templates as shared between the >two packages that contain them; then when wsympa is purged it will >remove it from the owners list of the questions but keep them around >since one other package still owns them. Reference counting.) Smart ;-) I love this. You've made my day! >> A same kind of problem is likely to happen for the conffiles and other >> non-conffiles configuration files that I move from wwsympa to sympa >> and that are been removed in wwsympa postrm. > > I'm afraid you're on your own there; dpkg does not deal with shared > conffiles well when the older package is removed I think it removes the > conffile. I see no real solution to this. One disgusting way for non-conffiles would be to delete the removing part: if [ -e /var/lib/dpkg/info/wwsympa.postrm ]; then sed fi I think you won't like this, will you? ;-) -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf questions and purge
Ian Zimmerman <[EMAIL PROTECTED]> writes: > Jerome> A same kind of problem is likely to happen for the conffiles > Jerome> and other non-conffiles configuration files that I move from > Jerome> wwsympa to sympa and that are been removed in wwsympa postrm. > > Joey> I'm afraid you're on your own there; dpkg does not deal with > Joey> shared conffiles well when the older package is removed I think > Joey> it removes the conffile. > > Surely you mean "when the older package is _purged_"? Yes, purged. > I have done "dpkg --remove oldname ; apt-get install newname" many > times on my system, and I think it works. It is ok with remove. -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debconf questions and purge
Hi, I need to merge the wwsympa package into sympa. Both packages use debconf. I wonder how I should merge wwsympa debconf templates into sympa's. In sympa, debconf variables start with sympa/ and wwsympa ones start with wwsympa/ If I keep the same variable name, I feel like I'm going to have problem if the user decide to purge wwsympa, because of db_purge. So do I really have to care for the purge and to rename variables? A same kind of problem is likely to happen for the conffiles and other non-conffiles configuration files that I move from wwsympa to sympa and that are been removed in wwsympa postrm. What is the bast way to handle this? Thanks in advance. Cheers, -- Jérôme Marant
Debconf questions and purge
Hi, I need to merge the wwsympa package into sympa. Both packages use debconf. I wonder how I should merge wwsympa debconf templates into sympa's. In sympa, debconf variables start with sympa/ and wwsympa ones start with wwsympa/ If I keep the same variable name, I feel like I'm going to have problem if the user decide to purge wwsympa, because of db_purge. So do I really have to care for the purge and to rename variables? A same kind of problem is likely to happen for the conffiles and other non-conffiles configuration files that I move from wwsympa to sympa and that are been removed in wwsympa postrm. What is the bast way to handle this? Thanks in advance. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libpng and the autobuilders
On Wed, Jul 31, 2002 at 09:50:56AM -0400, Michael Furr wrote: > On Wed, 2002-07-31 at 09:26, Jérôme Marant wrote: > > Replace libpng-dev with libpng3-dev. > How would that help things? It seems to me that from the log, the > problem isn't my build-dep, but rather that libpng3 "is not going to be > installed": > > Sorry, but the following packages have unmet dependencies: > > libpng-dev: Depends: libpng3 (= 1.2.1-1.1) but it is not going to be > > installed No, _libpng-dev_ is not going to be installed because it depends on a library that is no longer in the way. The right way to do is to replace libpng-dev with libpng3-dev which depends on the current libpng3. Cheers, -- Jérôme Marant
Re: libpng and the autobuilders
On Wed, Jul 31, 2002 at 09:24:51AM -0400, Michael Furr wrote: > Hi all, > > My package of vegastrike is stuck in the autobuilders. The problem lies > in its build-dep on libpng-dev. It needs to use version 3 of the lib. > I read all of the recent discussions on -devel about this issue but seem > to have missed the bottom line. How do I remedy this? Replace libpng-dev with libpng3-dev. Cheers, -- Jérôme Marant
Re: libpng and the autobuilders
On Wed, Jul 31, 2002 at 09:50:56AM -0400, Michael Furr wrote: > On Wed, 2002-07-31 at 09:26, Jérôme Marant wrote: > > Replace libpng-dev with libpng3-dev. > How would that help things? It seems to me that from the log, the > problem isn't my build-dep, but rather that libpng3 "is not going to be > installed": > > Sorry, but the following packages have unmet dependencies: > > libpng-dev: Depends: libpng3 (= 1.2.1-1.1) but it is not going to be > > installed No, _libpng-dev_ is not going to be installed because it depends on a library that is no longer in the way. The right way to do is to replace libpng-dev with libpng3-dev which depends on the current libpng3. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libpng and the autobuilders
On Wed, Jul 31, 2002 at 09:24:51AM -0400, Michael Furr wrote: > Hi all, > > My package of vegastrike is stuck in the autobuilders. The problem lies > in its build-dep on libpng-dev. It needs to use version 3 of the lib. > I read all of the recent discussions on -devel about this issue but seem > to have missed the bottom line. How do I remedy this? Replace libpng-dev with libpng3-dev. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Mon, Jul 29, 2002 at 10:28:50AM +0200, Sven LUTHER wrote: > On Mon, Jul 29, 2002 at 12:04:51AM +0100, Colin Watson wrote: > > On Sun, Jul 28, 2002 at 11:24:16AM -0400, christophe barb? wrote: > > > On Sun, Jul 28, 2002 at 01:04:07PM +1000, Jamie Wilkinson wrote: > > > > So in the control file, I've specified that libglut3 Conflicts and > > > > Replaces > > > > glutg3 for versions <= 3.7-15, and created a glutg3 package with no > > > > content, > > > > > > I am not sure but isn't it better to use 'Provides: glutg3' instead of > > > providing a package glutg3 with no content. > > > > Most dependencies on glutg3 are versioned, and a Provides: can't satisfy > > versioned dependencies. > > Are there any plans to fix dpkg so it finally supports versioned > provides ? AFAIK, there is a partial patch in dpkg CVS. APT needs to be modified in order to handle versioned provides as well. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Mon, Jul 29, 2002 at 10:28:50AM +0200, Sven LUTHER wrote: > On Mon, Jul 29, 2002 at 12:04:51AM +0100, Colin Watson wrote: > > On Sun, Jul 28, 2002 at 11:24:16AM -0400, christophe barb? wrote: > > > On Sun, Jul 28, 2002 at 01:04:07PM +1000, Jamie Wilkinson wrote: > > > > So in the control file, I've specified that libglut3 Conflicts and Replaces > > > > glutg3 for versions <= 3.7-15, and created a glutg3 package with no content, > > > > > > I am not sure but isn't it better to use 'Provides: glutg3' instead of > > > providing a package glutg3 with no content. > > > > Most dependencies on glutg3 are versioned, and a Provides: can't satisfy > > versioned dependencies. > > Are there any plans to fix dpkg so it finally supports versioned > provides ? AFAIK, there is a partial patch in dpkg CVS. APT needs to be modified in order to handle versioned provides as well. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SGML catalogs
On Fri, Jul 12, 2002 at 11:06:29AM +0200, Alexandre wrote: > On Fri, Jul 12, 2002 at 10:32:01AM +0200, Jérôme Marant wrote: > > On Fri, Jul 12, 2002 at 10:06:36AM +0200, Alexandre wrote: > > > Should the postinst scripts use udpate-catalog or install-sgmlcatalog to > > > register new catalog entries? > > > > IIRC, the xbel package uses such a registration mechanism, but with > > XML catalog. There might not be a lot of differences. > > That what I'm looking at currently (working on bug#148135 here), and I do > not see where xml is involved. The postinst script reads (tests, loops, > bells and whistles removed): > > PACKAGE=xbel > CENTRALCAT=/etc/sgml/$PACKAGE.cat > ORDCATS="misc/xbel/xbel.cat" > update-catalog --quiet --add $CENTRALCAT /usr/share/sgml/$ordcat > update-catalog --quiet --add --super $CENTRALCAT Well, I was told to use what is done in debiandoc-sgml and I changed the package that way. Sorry, I don't have any web access currently. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SGML catalogs
On Fri, Jul 12, 2002 at 11:06:29AM +0200, Alexandre wrote: > On Fri, Jul 12, 2002 at 10:32:01AM +0200, Jérôme Marant wrote: > > On Fri, Jul 12, 2002 at 10:06:36AM +0200, Alexandre wrote: > > > Should the postinst scripts use udpate-catalog or install-sgmlcatalog to > > > register new catalog entries? > > > > IIRC, the xbel package uses such a registration mechanism, but with > > XML catalog. There might not be a lot of differences. > > That what I'm looking at currently (working on bug#148135 here), and I do > not see where xml is involved. The postinst script reads (tests, loops, > bells and whistles removed): > > PACKAGE=xbel > CENTRALCAT=/etc/sgml/$PACKAGE.cat > ORDCATS="misc/xbel/xbel.cat" > update-catalog --quiet --add $CENTRALCAT /usr/share/sgml/$ordcat > update-catalog --quiet --add --super $CENTRALCAT Well, I was told to use what is done in debiandoc-sgml and I changed the package that way. Sorry, I don't have any web access currently. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SGML catalogs
On Fri, Jul 12, 2002 at 10:06:36AM +0200, Alexandre wrote: > Hello, > > I'm having some problems with SGML catalogs on a debian system. > > Should the postinst scripts use udpate-catalog or install-sgmlcatalog to > register new catalog entries? Hello, IIRC, the xbel package uses such a registration mechanism, but with XML catalog. There might not be a lot of differences. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SGML catalogs
On Fri, Jul 12, 2002 at 10:06:36AM +0200, Alexandre wrote: > Hello, > > I'm having some problems with SGML catalogs on a debian system. > > Should the postinst scripts use udpate-catalog or install-sgmlcatalog to > register new catalog entries? Hello, IIRC, the xbel package uses such a registration mechanism, but with XML catalog. There might not be a lot of differences. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: handling file name conflict
Alexandre <[EMAIL PROTECTED]> writes: > Hello, Hi, > What would be considered the best way to handle this ? You can call it pyro.ns . I've already experienced such a case in one of my packages. Cheers, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lib sdl
Robert Bihlmeyer <[EMAIL PROTECTED]> writes: > Jérôme Marant <[EMAIL PROTECTED]> writes: > >> > > You don't seem to have understood what cooperative work >> > > means. > > In another mail, Jérôme Marant <[EMAIL PROTECTED]> writes: > >> So what? The one who uploads the first wins. > [...] >> Obtaining permission is just a matter of courtesy. > > Pot. Kettle. Black. If I read the means of this "Pot. Kettle. Black." correctly, it has really nothing to do with what I said and how I said it. So Robert, please go back school and learn your English lessons this time. -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lib sdl
On Tue, Apr 30, 2002 at 02:25:35PM +0200, Andrea Mennucc wrote: > It seems you have different ideas; I am not losing my sleep on this. Don't worry, I know who I'm talking to ;-) -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lib sdl
On Tue, Apr 30, 2002 at 01:35:26PM +0200, Andrea Mennucc wrote: > What Christian Marillat has been doing was surely done with good intentions > in mind; and indeed I have already asked him for any help he wishes to > provide; but there were some problems/issues. > > (btw: didn't you ask yourself > "why Christian Marillat's package is not Debian?") Because I known why it has not been in Debian so far. > > > Let us review the history of mplayer-in-debian (afaik it) > > 0) mplayer has a debian directory in CVS; and it has been > possible to dpkg-buildpackage it using that directory for a long > time ( at least since 26 Feb 2001); Darius Pietrzak manages those files So what? I know some applications with a debian directory in CVS but with a different debian packaging in Debian. > 0bis) Darius Pietrzak has filed an ITP for mplayer in Debian wnpp [3] So what? The one who uploads the first wins. > 1) Christian Marillat has released many packages (the first on 26 Feb 2001, > according to the changelog); but > > 1a) he has not obtained permission from the authors: quite on the > opposite, the authors had asked to NOT package mplayer [1] [2] If you don't have permission to redistribute software as a Debian package, it is not free software. Obtaining permission is just a matter of courtesy. > 2a) the different parts of the source code of mplayer were subject to > different licenses, and this prohibited a binary packaging of > them all together [2] That's why it has not been in Debian so far. > > > > You don't seem to have understood what cooperative work > > means. > > you don't seem to have read the policy: it clearly states > > "We reserve the right to restrict files from being included anywhere in > our archives if > * their use or distribution would break a law, > * there is an ethical conflict in their distribution or use, > * we would have to sign a license for them, or > * their distribution would conflict with other project policies." It has nothing to do with the ongoing discussion. I didn't talk at all about not having it in Debian. You're just repackaging something that has already been packaged. > and in the mantainer's guide [4]: > # you should contact program's author(s) to check if they agree with > packaging it. It is important to be able to consult with author(s) > about the program in case of any program specific problems, so don't > try to package unmaintained pieces of software. Yes, you _should_, not you _must_. Please read it more carefully next time. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lib sdl
On Tue, Apr 30, 2002 at 02:25:35PM +0200, Andrea Mennucc wrote: > It seems you have different ideas; I am not losing my sleep on this. Don't worry, I know who I'm talking to ;-) -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lib sdl
On Tue, Apr 30, 2002 at 01:35:26PM +0200, Andrea Mennucc wrote: > What Christian Marillat has been doing was surely done with good intentions > in mind; and indeed I have already asked him for any help he wishes to > provide; but there were some problems/issues. > > (btw: didn't you ask yourself > "why Christian Marillat's package is not Debian?") Because I known why it has not been in Debian so far. > > > Let us review the history of mplayer-in-debian (afaik it) > > 0) mplayer has a debian directory in CVS; and it has been > possible to dpkg-buildpackage it using that directory for a long > time ( at least since 26 Feb 2001); Darius Pietrzak manages those files So what? I know some applications with a debian directory in CVS but with a different debian packaging in Debian. > 0bis) Darius Pietrzak has filed an ITP for mplayer in Debian wnpp [3] So what? The one who uploads the first wins. > 1) Christian Marillat has released many packages (the first on 26 Feb 2001, > according to the changelog); but > > 1a) he has not obtained permission from the authors: quite on the > opposite, the authors had asked to NOT package mplayer [1] [2] If you don't have permission to redistribute software as a Debian package, it is not free software. Obtaining permission is just a matter of courtesy. > 2a) the different parts of the source code of mplayer were subject to > different licenses, and this prohibited a binary packaging of > them all together [2] That's why it has not been in Debian so far. > > > > You don't seem to have understood what cooperative work > > means. > > you don't seem to have read the policy: it clearly states > > "We reserve the right to restrict files from being included anywhere in > our archives if > * their use or distribution would break a law, > * there is an ethical conflict in their distribution or use, > * we would have to sign a license for them, or > * their distribution would conflict with other project policies." It has nothing to do with the ongoing discussion. I didn't talk at all about not having it in Debian. You're just repackaging something that has already been packaged. > and in the mantainer's guide [4]: > # you should contact program's author(s) to check if they agree with > packaging it. It is important to be able to consult with author(s) > about the program in case of any program specific problems, so don't > try to package unmaintained pieces of software. Yes, you _should_, not you _must_. Please read it more carefully next time. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lib sdl
Andrea Mennucc <[EMAIL PROTECTED]> writes: > hi > > I am helping packaging mplayer; it depends on libsdl; > I see that there is a libsdl1.2debian* series, and I heard > that this is the best to be used in Debian; problem is, there is no > libsdl1.2debian-dev, so I don't understand what we should put in > Depends and Build-depends fields. Sorry, but I don't really understand why you are working on reinventing packaging that has already been done by Christian Marillat at http://marillat.free.fr. You don't seem to have understood what cooperative work means. -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lib sdl
Andrea Mennucc <[EMAIL PROTECTED]> writes: > hi > > I am helping packaging mplayer; it depends on libsdl; > I see that there is a libsdl1.2debian* series, and I heard > that this is the best to be used in Debian; problem is, there is no > libsdl1.2debian-dev, so I don't understand what we should put in > Depends and Build-depends fields. Sorry, but I don't really understand why you are working on reinventing packaging that has already been done by Christian Marillat at http://marillat.free.fr. You don't seem to have understood what cooperative work means. -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package uploaded by my sponsor
On Wed, Apr 17, 2002 at 02:59:09PM +0200, Cédric Delfosse wrote: > Hello mentors ! > > 1. I have ITP a package called xmms-iris. > 2. My sponsor ([EMAIL PROTECTED]) uploaded it > 3. My sponsor and I have received acknowledgment (04 Apr 2002) that the > package is new, and that something must be done so that the package is > taken in account. > 4. I'm still waiting for something to happen. > > Is there a way to know what is happening to my package ? > Should I worry ? It is new so ftp-masters have to process them by hand so it takes more times and is currently lower priority. Just please wait. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared __init__.py file accross multiple python packages
On Fri, Apr 12, 2002 at 04:46:43PM +0200, Alexandre wrote: > On Fri, Apr 12, 2002 at 04:30:14PM +0200, Jérôme Marant wrote: > > On Fri, Apr 12, 2002 at 03:43:58PM +0200, Alexandre wrote: > > > On Fri, Apr 12, 2002 at 03:21:04PM +0200, Jérôme Marant wrote: > > > > > > > Are the modules you're packaging part of the same source or are > > > > they independant ? > > > > > > They are independand. These are modules developed by my company, and our > > > policy is to have them live in a top level directory called 'logilab' > > > under site-packages/, so it's not quite the same thing as the egenix > > > packages. > > > > If there is not really something relevant for a dedicated common > > package, you can always add something like this in the postinst > > script of every logilab package: > > > Looks nice. I'd have to do something in the postrm script of each > package to check if there are still some packages in the logilab > directory and remove the __init__.py file together with the logilab > directory, right? Well, it is not necessary. It could be the user's responsibility to remove it since dpkg will tell you that is was not removed. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared __init__.py file accross multiple python packages
On Fri, Apr 12, 2002 at 03:43:58PM +0200, Alexandre wrote:
> On Fri, Apr 12, 2002 at 03:21:04PM +0200, Jérôme Marant wrote:
>
> > Are the modules you're packaging part of the same source or are
> > they independant ?
>
> They are independand. These are modules developed by my company, and our
> policy is to have them live in a top level directory called 'logilab'
> under site-packages/, so it's not quite the same thing as the egenix
> packages.
If there is not really something relevant for a dedicated common
package, you can always add something like this in the postinst
script of every logilab package:
VER=2.1
TOPLEVEL=/usr/lib/python$VER/site-packages/logilab
if [ ! -e $TOPLEVEL/__init__.py ]; then
touch $TOPLEVEL/__init__.py
fi
--
Jérôme Marant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared __init__.py file accross multiple python packages
On Fri, Apr 12, 2002 at 03:16:46PM +0200, Alexandre wrote: > Hello, > > I'm trying to roll up my first debian packages, and I could do with some > advice (please refer me to the right piece of documentation if I appear > to have missed it). > > I'm actually packaging several (8) python modules that are to live in a > common subdirectory of /usr/lib/pythonX.X/site-packages/. They all share > an empty __init__.py file in this common subdirectory. From what I > understand, this means that if nothing is done, they will conflict. > > What appears to be a standard solution is to have another package > provide the shared files, and make the other modules depend on this new > package. Now, here's the naive question: what's the right way of doing > this? Should I create the common dependency in one of the source > packages, or create a new source package with the required file? Or > something else? Are the modules you're packaging part of the same source or are they independant ? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared __init__.py file accross multiple python packages
On Fri, Apr 12, 2002 at 04:46:43PM +0200, Alexandre wrote: > On Fri, Apr 12, 2002 at 04:30:14PM +0200, Jérôme Marant wrote: > > On Fri, Apr 12, 2002 at 03:43:58PM +0200, Alexandre wrote: > > > On Fri, Apr 12, 2002 at 03:21:04PM +0200, Jérôme Marant wrote: > > > > > > > Are the modules you're packaging part of the same source or are > > > > they independant ? > > > > > > They are independand. These are modules developed by my company, and our > > > policy is to have them live in a top level directory called 'logilab' > > > under site-packages/, so it's not quite the same thing as the egenix > > > packages. > > > > If there is not really something relevant for a dedicated common > > package, you can always add something like this in the postinst > > script of every logilab package: > > > Looks nice. I'd have to do something in the postrm script of each > package to check if there are still some packages in the logilab > directory and remove the __init__.py file together with the logilab > directory, right? Well, it is not necessary. It could be the user's responsibility to remove it since dpkg will tell you that is was not removed. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared __init__.py file accross multiple python packages
On Fri, Apr 12, 2002 at 03:43:58PM +0200, Alexandre wrote:
> On Fri, Apr 12, 2002 at 03:21:04PM +0200, Jérôme Marant wrote:
>
> > Are the modules you're packaging part of the same source or are
> > they independant ?
>
> They are independand. These are modules developed by my company, and our
> policy is to have them live in a top level directory called 'logilab'
> under site-packages/, so it's not quite the same thing as the egenix
> packages.
If there is not really something relevant for a dedicated common
package, you can always add something like this in the postinst
script of every logilab package:
VER=2.1
TOPLEVEL=/usr/lib/python$VER/site-packages/logilab
if [ ! -e $TOPLEVEL/__init__.py ]; then
touch $TOPLEVEL/__init__.py
fi
--
Jérôme Marant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared __init__.py file accross multiple python packages
On Fri, Apr 12, 2002 at 03:16:46PM +0200, Alexandre wrote: > Hello, > > I'm trying to roll up my first debian packages, and I could do with some > advice (please refer me to the right piece of documentation if I appear > to have missed it). > > I'm actually packaging several (8) python modules that are to live in a > common subdirectory of /usr/lib/pythonX.X/site-packages/. They all share > an empty __init__.py file in this common subdirectory. From what I > understand, this means that if nothing is done, they will conflict. > > What appears to be a standard solution is to have another package > provide the shared files, and make the other modules depend on this new > package. Now, here's the naive question: what's the right way of doing > this? Should I create the common dependency in one of the source > packages, or create a new source package with the required file? Or > something else? Are the modules you're packaging part of the same source or are they independant ? -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary addition in the debian .diff.gz
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > On Wed, 6 Mar 2002, Jérôme Marant wrote: > >> The only way to do it is to uuencode the binary data (so add a build >> dependency on sharutils) and uudecode through debian/rules. >> > > Note you can also use pack (and unpack) u in perl and thereby avoid the > extra dependency. Thanks for the advice. I was not aware of such a facility. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: binary addition in the debian .diff.gz
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > On Wed, 6 Mar 2002, Jérôme Marant wrote: > >> The only way to do it is to uuencode the binary data (so add a build >> dependency on sharutils) and uudecode through debian/rules. >> > > Note you can also use pack (and unpack) u in perl and thereby avoid the > extra dependency. Thanks for the advice. I was not aware of such a facility. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary addition in the debian .diff.gz
On Wed, Mar 06, 2002 at 04:56:32PM +0100, Sven wrote: > Well, you could issue a new tarball of the same version, something like > zoggy_0.91a.orig.tar.gz, including the manual, and then have no worry about > the .diff.gz. The .orig.tar.gz should be the pristine upstream tarball (.i.e. same MD5 sum) whenever possible. The diff file is dedicated to debian packaging specifics. That's why changing the diff only is a better packaging practice. Cheers, -- Jérôme Marant
Re: binary addition in the debian .diff.gz
On Wed, Mar 06, 2002 at 04:56:32PM +0100, Sven wrote: > Well, you could issue a new tarball of the same version, something like > zoggy_0.91a.orig.tar.gz, including the manual, and then have no worry about > the .diff.gz. The .orig.tar.gz should be the pristine upstream tarball (.i.e. same MD5 sum) whenever possible. The diff file is dedicated to debian packaging specifics. That's why changing the diff only is a better packaging practice. Cheers, -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary addition in the debian .diff.gz
On Wed, Mar 06, 2002 at 10:02:54AM +0100, Stefano Zacchiroli wrote: > Hi mentors, > Does exists a way to tell dpkg-buildpackage to include also binary diff > in the .diff.gz? > This seems to me almost impossible, but ... you are the mentors :) The only way to do it is to uuencode the binary data (so add a build dependency on sharutils) and uudecode through debian/rules. Cheers, -- Jérôme Marant
