Re: Renaming a package and its corresponding debug package
2014-05-30 20:51 GMT+01:00 Jakub Wilk jw...@debian.org: * Ghislain Vaillant ghisv...@gmail.com, 2014-05-30, 15:45: Basically, if I install python-fftw3 and call `dpkg -i python-pyfftw.deb`, then dpkg figures out the replacement, uninstall python-fftw3 and configure and install python-pyfftw. If I install python-fftw3-dbg, and python-fftw3 automatically as a result the dependency, then `dpkg -i python-pyfftw.deb python-pyfftw-dbg.deb` does figure out the replacement of the -dbg package but fails on the main package. Try in the opposite order: dpkg -i python-pyfftw-dbg.deb python-pyfftw.deb apt-get install would likely figure the correct order of debs. However, apt-get dist-upgrade won't know how to upgrade the old packages. So you probably need transitional packages: https://wiki.debian.org/Renaming_a_Package -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530195111.ga4...@jwilk.net A transitional package would probably be overkill for a package whose sole reverse dependency is its debug package. Besides, the package is fairly new to the main archive, so damages are likely to remain very limited if not inexistent. Could I just indicate the change in NEWS so apt-listchanges indicate that breackage could happen if the -dbg is installed and that the solution is to just let aptitude remove it and install the renamed -dbg ? Ghis
Re: Renaming a package and its corresponding debug package
* Ghislain Vaillant ghisv...@gmail.com, 2014-05-31, 10:16: apt-get install would likely figure the correct order of debs. However, apt-get dist-upgrade won't know how to upgrade the old packages. So you probably need transitional packages: https://wiki.debian.org/Renaming_a_Package A transitional package would probably be overkill for a package whose sole reverse dependency is its debug package. Besides, the package is fairly new to the main archive, so damages are likely to remain very limited if not inexistent. Well, the packages have non-zero popcon... But maybe you're right it would be overkill. Could I just indicate the change in NEWS so apt-listchanges indicate that breackage could happen if the -dbg is installed and that the solution is to just let aptitude remove it and install the renamed -dbg ? As I understand it, no breakage should happen; it's just the packages won't get upgraded (unless the user manually requests to install those with new names). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140531165300.ga1...@jwilk.net
Re: Renaming a package and its corresponding debug package
* Ghislain Vaillant ghisv...@gmail.com, 2014-05-30, 09:44:
Now say I want to rename the -foo suffix into -bar for both package
python-foo and python-foo-dbg. The debian developer's reference
suggests to Conflicts/Replaces/Provides the old name and change the
name of the package to the new name in the corresponding d/control
entries. I tried it and it worked well for python-foo to python-bar.
However, dpkg does not handle the transition from python-foo-dbg to
python-bar-dbg properly. You can find more information about the dpkg
commands and modifications to d/control of the package in the original
post linked above.
The modifications you made look all right too me:
Package: python-pyfftw-dbg
Architecture: any
Priority: extra
Section: debug
Depends:
${misc:Depends},
${python:Depends},
${shlibs:Depends},
python-pyfftw (= ${binary:Version})
Recommends:
python-dbg,
python-numpy-dbg
Provides: python-fftw3-dbg
Conflicts: python-fftw3-dbg
Replaces: python-fftw3-dbg
We probably need more information about this. You only wrote that dpkg
fails to perform the upgrade. But what exactly did you do, and
how did it fail?
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140530133703.ga7...@jwilk.net
Re: Renaming a package and its corresponding debug package
2014-05-30 14:37 GMT+01:00 Jakub Wilk jw...@debian.org:
* Ghislain Vaillant ghisv...@gmail.com, 2014-05-30, 09:44:
Now say I want to rename the -foo suffix into -bar for both package
python-foo and python-foo-dbg. The debian developer's reference suggests to
Conflicts/Replaces/Provides the old name and change the name of the package
to the new name in the corresponding d/control entries. I tried it and it
worked well for python-foo to python-bar. However, dpkg does not handle the
transition from python-foo-dbg to python-bar-dbg properly. You can find
more information about the dpkg commands and modifications to d/control of
the package in the original post linked above.
The modifications you made look all right too me:
Package: python-pyfftw-dbg
Architecture: any
Priority: extra
Section: debug
Depends:
${misc:Depends},
${python:Depends},
${shlibs:Depends},
python-pyfftw (= ${binary:Version})
Recommends:
python-dbg,
python-numpy-dbg
Provides: python-fftw3-dbg
Conflicts: python-fftw3-dbg
Replaces: python-fftw3-dbg
We probably need more information about this. You only wrote that dpkg
fails to perform the upgrade. But what exactly did you do, and how did it
fail?
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/20140530133703.ga7...@jwilk.net
Basically, if I install python-fftw3 and call `dpkg -i python-pyfftw.deb`,
then dpkg figures out the replacement, uninstall python-fftw3 and configure
and install python-pyfftw.
If I install python-fftw3-dbg, and python-fftw3 automatically as a result
the dependency, then `dpkg -i python-pyfftw.deb python-pyfftw-dbg.deb` does
figure out the replacement of the -dbg package but fails on the main
package. Then calling the same command a second time, dpkg works out the
replacement of the main package. So essentially, I need to first call `dpkg
-i` on the -dbg package and then call it a second time on the main package
I would expect dpkg to be smart and figure out that both the -dbg and main
package should be replaced at once, and though this was not happening
because something is wrong in my d/control. Maybe this is beyond dpkg's job
and apt or aptitude would handle that just fine.
Thoughts ?
Ghis
Re: Renaming a package and its corresponding debug package
Maybe this is beyond dpkg's job and apt or aptitude would handle that just fine. I suspect that's the issue: I don't think dpkg knows how to find packages you didn't explicitly give it (sources.list is in /etc/apt, not /etc/dpkg...), so if dependencies require other packages it will error out rather than installing them. (To test locally with apt, you can use apt-ftparchive (https://wiki.debian.org/PbuilderTricks) or mini-dinstall (https://wiki.ubuntu.com/PbuilderHowto#Building_With_Local_Packages).) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5388b851.4000...@bham.ac.uk
Re: Renaming a package and its corresponding debug package
* Ghislain Vaillant ghisv...@gmail.com, 2014-05-30, 15:45: Basically, if I install python-fftw3 and call `dpkg -i python-pyfftw.deb`, then dpkg figures out the replacement, uninstall python-fftw3 and configure and install python-pyfftw. If I install python-fftw3-dbg, and python-fftw3 automatically as a result the dependency, then `dpkg -i python-pyfftw.deb python-pyfftw-dbg.deb` does figure out the replacement of the -dbg package but fails on the main package. Try in the opposite order: dpkg -i python-pyfftw-dbg.deb python-pyfftw.deb apt-get install would likely figure the correct order of debs. However, apt-get dist-upgrade won't know how to upgrade the old packages. So you probably need transitional packages: https://wiki.debian.org/Renaming_a_Package -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530195111.ga4...@jwilk.net
Re: Renaming the package and other things
Hi! Christoph Berg wrote: Re: Nelson A. de Oliveira in [EMAIL PROTECTED] I am planning to rename the source package to biofox only, instead mozilla-firefox-biofox. Why? The user won't see the source package name change. It's only extra hassle for you and the ftp-masters. If you really want, rename the binary package only. NB, how does upstream call the package/program/tarball? Upstream names it biofox only. Yes, I know. I've made a mistake using the same name on the binary and on the source package :-( That happened because biofox, as the name says, was only to Firefox. Upstream author changed this now and made it available also to Mozilla. I want to correct my mistake now to avoid bigger problems later. What I am thinking is: Source package: biofox Binary package: biofox (that can be used both on Firefox and on Mozilla Suite) Binary package: mozilla-firefox-biofox (transitional dummy package depending on biofox, so users will upgrade to the new biofox). Doubt: Does biofox (the binary package) must use Conflicts, Provides and/or Replaces? Thank you very much Regards, Nelson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming the package and other things
On Tue, Sep 13, 2005 at 12:48:46AM -0300, Nelson A. de Oliveira wrote: Hi! Christoph Berg wrote: Re: Nelson A. de Oliveira in [EMAIL PROTECTED] I am planning to rename the source package to biofox only, instead mozilla-firefox-biofox. Why? The user won't see the source package name change. It's only extra hassle for you and the ftp-masters. If you really want, rename the binary package only. NB, how does upstream call the package/program/tarball? Upstream names it biofox only. Yes, I know. I've made a mistake using the same name on the binary and on the source package :-( That happened because biofox, as the name says, was only to Firefox. Upstream author changed this now and made it available also to Mozilla. I want to correct my mistake now to avoid bigger problems later. What I am thinking is: Source package: biofox Binary package: biofox (that can be used both on Firefox and on Mozilla Suite) Binary package: mozilla-firefox-biofox (transitional dummy package depending on biofox, so users will upgrade to the new biofox). Doubt: Does biofox (the binary package) must use Conflicts, Provides and/or Replaces? I think it needs replaces, since it will contain files which used to be in binary package mozilla-firefox-biofox. If biofox is unpacked before m-f-b is unpacked, there will be a problem (and you don't want to have to invent a strange way of guaranteeing some certain order). It shouldn't use Conflicts, because if it conflicted with m-f-b, then m-f-b would be uninstallable (no consistent way to have it installed). It shouldn't need Provides, because your transition scheme works. (Users which presently have m-f-b installed will end up with biofox installed.) Please be sure to change the long description of m-f-b to include the word transitional such that some tools will pick up on it. (And remember to remove it post-etch, I guess). It doesn't need conflicts+provides+replaces, because that is a special-case combination which dpkg interprets as this binary package is the new name of some old binary package (right?). -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming the package and other things
On Sun, Sep 11, 2005 at 10:31:06PM -0300, Nelson A. de Oliveira wrote: Hi! I am maintaining a package called mozilla-firefox-biofox. Both ths source and the binary package have the same name. Biofox was always released only to Mozilla Firefox and the Mozilla Suite was not supported. However, upstream author changed this now. Biofox supports both navigators. I am planning to rename the source package to biofox only, instead mozilla-firefox-biofox. May I do this? How can I do this? Is it there some policy saying about renaming a source package? Yes; its going to be a new package, that has to go through the NEW queue (right?) Its going to happen to be from the same upstream project as a soon-to-be old and removed package, though. I think the recommendation is, in this type of case, to preserve the changelog in the new package, so you could have an entry such as: * Rename source to biofox. ... Right. Second problem now. If I create two binary packages, one mozilla-firefox and another Huh? Surely that name is a mistake? :) mozilla-biobar? mozilla-firefox-biobar, basically they will have the same files. If I create only one package (maybe named biofox only), this package will depends on mozilla | mozilla-firefox and I will put the files inside Firefox dir, for example, and create links on Mozilla dir, pointing to the files on the Firefox dir (to avoid duplicated files). Can't you just have a symlink pointing to a directory, instead of a real directory filled with a symlink farm? Create 2 binary packages or just one, as I said? Just one, I think, because otherwise there are duplicate files in different packages, which smells bad, and there's the overhead of one more package. If the one package only is the best thing to do, I must put a Replaces, Conflicts and Provides, like this? Replaces: mozilla-firefox-biofox Conflicts: mozilla-firefox-biofox Provides: mozilla-firefox-biofox Yes, I think. It is late, though, so I had to look it up... -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming the package and other things
* Justin Pryzby [Mon, 12 Sep 2005 01:52:32 -0400]: On Sun, Sep 11, 2005 at 10:31:06PM -0300, Nelson A. de Oliveira wrote: I am planning to rename the source package to biofox only, instead mozilla-firefox-biofox. May I do this? How can I do this? Is it there some policy saying about renaming a source package? Yes; its going to be a new package, that has to go through the NEW queue (right?) Its going to happen to be from the same upstream project as a soon-to-be old and removed package, though. NEW queue is for binary packages only, afaik. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Don't ask the barber whether you need a haircut. -- Daniel S. Greenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming the package and other things
Re: Nelson A. de Oliveira in [EMAIL PROTECTED] I am planning to rename the source package to biofox only, instead mozilla-firefox-biofox. Why? The user won't see the source package name change. It's only extra hassle for you and the ftp-masters. If you really want, rename the binary package only. NB, how does upstream call the package/program/tarball? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: renaming source package
Stefano Zacchiroli wrote: On Tue, May 04, 2004 at 03:11:41PM +0200, Rene Engelhard wrote: would it be possible to upload the new package before the old one is removed? Yes. BTW I've just discovered another problem in this renaming. Previous upstream author used timestamp based versioning with last version 20040120 while new upstream author has actually has a last version 1.3.3. Obviously 1.3.3 is less then 20040120, how can I cope with this issue? Well, if you're uploading a package with a new name, what's the problem? -- There are none so blind as those who will not see.
Re: renaming source package
Stefano Zacchiroli wrote: On Tue, May 04, 2004 at 03:11:41PM +0200, Rene Engelhard wrote: would it be possible to upload the new package before the old one is removed? Yes. BTW I've just discovered another problem in this renaming. Previous upstream author used timestamp based versioning with last version 20040120 while new upstream author has actually has a last version 1.3.3. Obviously 1.3.3 is less then 20040120, how can I cope with this issue? Well, if you're uploading a package with a new name, what's the problem? -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stefano Zacchiroli wrote: The other approach is to ask for removal of the old source package and upload a new one which generates the same binary packages. This seems to be the best approach but I'm a bit scared about the transition phase ... I agree. would it be possible to upload the new package before the old one is removed? Yes. Grüße/Regards, René - -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAl5aN+FmQsCSK63MRAv7SAJ9f2BZJDaM7w5z61n32Rk9ZgBpUEQCfZtMa q5wp81LqD33+wy4kAjulPM8= =qD8f -END PGP SIGNATURE-
Re: renaming source package
On Tue, May 04, 2004 at 03:11:41PM +0200, Rene Engelhard wrote: would it be possible to upload the new package before the old one is removed? Yes. BTW I've just discovered another problem in this renaming. Previous upstream author used timestamp based versioning with last version 20040120 while new upstream author has actually has a last version 1.3.3. Obviously 1.3.3 is less then 20040120, how can I cope with this issue? TIA, Cheers -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: renaming source package
Hi. Stefano Zacchiroli ([EMAIL PROTECTED]) wrote: Obviously 1.3.3 is less then 20040120, how can I cope with this issue? Epoch. 1:1.3.3 20040120. Cheers T.
Re: renaming source package
On Tue, May 04, 2004 at 04:49:22PM +0200, Stefano Zacchiroli wrote: On Tue, May 04, 2004 at 03:11:41PM +0200, Rene Engelhard wrote: would it be possible to upload the new package before the old one is removed? Yes. BTW I've just discovered another problem in this renaming. Previous upstream author used timestamp based versioning with last version 20040120 while new upstream author has actually has a last version 1.3.3. Due the renaming it is no problem (foo-20040120, bar-1.3.3). Obviously 1.3.3 is less then 20040120, how can I cope with this issue? That is where an epoch comes in. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version TIA, Cheers Geert Stappers pgpIlcmEqeIi7.pgp Description: PGP signature
Re: renaming source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stefano Zacchiroli wrote: Obviously 1.3.3 is less then 20040120, how can I cope with this issue? epoch. Grüße/Regards, René - -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAl7nD+FmQsCSK63MRAgk0AJ41RN1GozPRT3/Pe/E5JG8ucso65wCgg5ek 4Z9/IIkPwcF8xU+zXt6Gk0M= =a3Nr -END PGP SIGNATURE-
Re: renaming source package
Stefano Zacchiroli [EMAIL PROTECTED] writes: Upstream maintainership of a package of mine changed from the old author to a new one. New upstream maintainer decided to change the source name of the package and thus the tarball name. How can I handle such a change? The simplest approach seems to be to keep the currend debian source package name and just release a new upstream release version of the package. Actually I haven't yet tried and I don't know if uupdate permits that, but in case it doesn't I can simply rename the tarball. The other approach is to ask for removal of the old source package and upload a new one which generates the same binary packages. This seems to be the best approach but I'm a bit scared about the transition phase ... would it be possible to upload the new package before the old one is removed? TIA, Cheers. Just upload the new one. Both sources will be there since they don't conflict. In the binary packages (if you rename any of them) set Conflicts/Replaces/Provides. Don't request removal of the old package untill _all_ architectures have build the new package. Best wait for it to enter sarge so sid and sarge can be cleaned up together. MfG Goswin
Re: renaming source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stefano Zacchiroli wrote: The other approach is to ask for removal of the old source package and upload a new one which generates the same binary packages. This seems to be the best approach but I'm a bit scared about the transition phase ... I agree. would it be possible to upload the new package before the old one is removed? Yes. Grüße/Regards, René - -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAl5aN+FmQsCSK63MRAv7SAJ9f2BZJDaM7w5z61n32Rk9ZgBpUEQCfZtMa q5wp81LqD33+wy4kAjulPM8= =qD8f -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stefano Zacchiroli wrote: Obviously 1.3.3 is less then 20040120, how can I cope with this issue? epoch. Grüße/Regards, René - -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAl7nD+FmQsCSK63MRAgk0AJ41RN1GozPRT3/Pe/E5JG8ucso65wCgg5ek 4Z9/IIkPwcF8xU+zXt6Gk0M= =a3Nr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming source package
Stefano Zacchiroli [EMAIL PROTECTED] writes: Upstream maintainership of a package of mine changed from the old author to a new one. New upstream maintainer decided to change the source name of the package and thus the tarball name. How can I handle such a change? The simplest approach seems to be to keep the currend debian source package name and just release a new upstream release version of the package. Actually I haven't yet tried and I don't know if uupdate permits that, but in case it doesn't I can simply rename the tarball. The other approach is to ask for removal of the old source package and upload a new one which generates the same binary packages. This seems to be the best approach but I'm a bit scared about the transition phase ... would it be possible to upload the new package before the old one is removed? TIA, Cheers. Just upload the new one. Both sources will be there since they don't conflict. In the binary packages (if you rename any of them) set Conflicts/Replaces/Provides. Don't request removal of the old package untill _all_ architectures have build the new package. Best wait for it to enter sarge so sid and sarge can be cleaned up together. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
So it is no bug that this file-conflict
| X:/ dpkg -i /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| dpkg - warning: downgrading pgrep from 4.5-0.1 to 4.3-0.0.1.
| (Reading database ... 9669 files and directories currently installed.)
| Preparing to replace pgrep 4.5-0.1 (using
| .../pgrep_4.3-0.0.1_i386.deb) ...
| Unpacking replacement pgrep ...
| dpkg: error processing /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| (--install):
| trying to overwrite `/usr/bin/pcregrep', which is also in package
| pcregrep
| Errors were encountered while processing:
| /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
is not expressed in Conflicts: because basically we only care about
upgrading?
cu andreas
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On Sun, Mar 07, 2004 at 01:17:46PM +0100, Andreas Metzler wrote:
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Actually, Replaces:/Conflicts: has the special meaning of this package
completely replaces that other package, which I guess is what you want.
Nothing depends on pgrep, so is the dummy package really needed?
So it is no bug that this file-conflict
| X:/ dpkg -i /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| dpkg - warning: downgrading pgrep from 4.5-0.1 to 4.3-0.0.1.
| (Reading database ... 9669 files and directories currently installed.)
| Preparing to replace pgrep 4.5-0.1 (using
| .../pgrep_4.3-0.0.1_i386.deb) ...
| Unpacking replacement pgrep ...
| dpkg: error processing /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| (--install):
| trying to overwrite `/usr/bin/pcregrep', which is also in package
| pcregrep
| Errors were encountered while processing:
| /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
is not expressed in Conflicts: because basically we only care about
upgrading?
That's really a bug in dpkg.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 01:17:46PM +0100, Andreas Metzler wrote:
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Actually, Replaces:/Conflicts: has the special meaning of this package
completely replaces that other package, which I guess is what you want.
Nothing depends on pgrep, so is the dummy package really needed?
[...]
Yes. If you have pgrep installed and there is no dummy package neither
apt-get (dist-)upgrade nor dselect will install pcregrep. The
outdated package will be kept indefinitely.
cu andreas
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On Sun, Mar 07, 2004 at 01:17:46PM +0100, Andreas Metzler wrote:
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Actually, Replaces:/Conflicts: has the special meaning of this package
completely replaces that other package, which I guess is what you want.
Nothing depends on pgrep, so is the dummy package really needed?
So it is no bug that this file-conflict
| X:/ dpkg -i /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| dpkg - warning: downgrading pgrep from 4.5-0.1 to 4.3-0.0.1.
| (Reading database ... 9669 files and directories currently installed.)
| Preparing to replace pgrep 4.5-0.1 (using
| .../pgrep_4.3-0.0.1_i386.deb) ...
| Unpacking replacement pgrep ...
| dpkg: error processing /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| (--install):
| trying to overwrite `/usr/bin/pcregrep', which is also in package
| pcregrep
| Errors were encountered while processing:
| /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
is not expressed in Conflicts: because basically we only care about
upgrading?
That's really a bug in dpkg.
--
Colin Watson [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 01:17:46PM +0100, Andreas Metzler wrote:
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling
(4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Actually, Replaces:/Conflicts: has the special meaning of this package
completely replaces that other package, which I guess is what you want.
Nothing depends on pgrep, so is the dummy package really needed?
[...]
Yes. If you have pgrep installed and there is no dummy package neither
apt-get (dist-)upgrade nor dselect will install pcregrep. The
outdated package will be kept indefinitely.
cu andreas
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
Re: Renaming a package
On Sat, Oct 04, 2003 at 05:16:53PM -0500, Manoj Srivastava wrote: On Sat, 4 Oct 2003 10:03:11 +0200, Andreas Metzler [EMAIL PROTECTED] said: [...] quoting a recent discussion on debian-devel: -- From: Andrew Suffield [EMAIL PROTECTED] To: [...] Mindless optimism. If you try skipping a release on a box with a fair amount of stuff installed, expect to spend all day fixing it. -- The response should be to determine where these glitches lie and fix them, rather than just compromising on quality. Go ahead, invest your time if you think it is important enough. Personally I think there is (and will always be) more important work to do while Debian's release interval is 12 Months. I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). Sounds like a bug to me. Could you be more verbose what you consider to be a bug? [ ] The fact that we don't regularily make test installations of sid packages on potato [ ] The fact that potato's bash has some bugs that sid's one does not. [ ] Something else. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Sun, 5 Oct 2003 00:58:37 +0200, Andreas Metzler [EMAIL PROTECTED] said: On Sat, Oct 04, 2003 at 05:16:53PM -0500, Manoj Srivastava wrote: On Sat, 4 Oct 2003 10:03:11 +0200, Andreas Metzler [EMAIL PROTECTED] said: [...] quoting a recent discussion on debian-devel: -- From: Andrew Suffield [EMAIL PROTECTED] To: [...] Mindless optimism. If you try skipping a release on a box with a fair amount of stuff installed, expect to spend all day fixing it. -- The response should be to determine where these glitches lie and fix them, rather than just compromising on quality. Go ahead, invest your time if you think it is important enough. Personally I think there is (and will always be) more important work to do while Debian's release interval is 12 Months. I understand that the lure of fresh commits is often greater than quality control; especially in little corner cases like this that nevertheless contribute to the quality of the distribution. But that is a far cry from deliberately going out of our way to break compatibility by removing the dummy package prematurely. I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). Sounds like a bug to me. Could you be more verbose what you consider to be a bug? [ ] The fact that we don't regularily make test installations of sid packages on potato Regularily? Or ever? [ ] The fact that potato's bash has some bugs that sid's one does not. Do we need to use these features that would break potato's bash in install scripts? Used to be the case that one was careful and minimalistic in installation. Hmm. I'll be testing my packages out in a potato chroot to be sure. [ ] Something else. Breaking our traditional compatibility from the version before stable in to unstable (though perhaps that tradition has been broken as often as it has een observed of late). manoj -- I put instant coffee in a microwave and almost went back in time. Steven Wright Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Sat, Oct 04, 2003 at 05:16:53PM -0500, Manoj Srivastava wrote: On Sat, 4 Oct 2003 10:03:11 +0200, Andreas Metzler [EMAIL PROTECTED] said: [...] quoting a recent discussion on debian-devel: -- From: Andrew Suffield [EMAIL PROTECTED] To: [...] Mindless optimism. If you try skipping a release on a box with a fair amount of stuff installed, expect to spend all day fixing it. -- The response should be to determine where these glitches lie and fix them, rather than just compromising on quality. Go ahead, invest your time if you think it is important enough. Personally I think there is (and will always be) more important work to do while Debian's release interval is 12 Months. I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). Sounds like a bug to me. Could you be more verbose what you consider to be a bug? [ ] The fact that we don't regularily make test installations of sid packages on potato [ ] The fact that potato's bash has some bugs that sid's one does not. [ ] Something else. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Renaming a package
On Sun, 5 Oct 2003 00:58:37 +0200, Andreas Metzler [EMAIL PROTECTED] said: On Sat, Oct 04, 2003 at 05:16:53PM -0500, Manoj Srivastava wrote: On Sat, 4 Oct 2003 10:03:11 +0200, Andreas Metzler [EMAIL PROTECTED] said: [...] quoting a recent discussion on debian-devel: -- From: Andrew Suffield [EMAIL PROTECTED] To: [...] Mindless optimism. If you try skipping a release on a box with a fair amount of stuff installed, expect to spend all day fixing it. -- The response should be to determine where these glitches lie and fix them, rather than just compromising on quality. Go ahead, invest your time if you think it is important enough. Personally I think there is (and will always be) more important work to do while Debian's release interval is 12 Months. I understand that the lure of fresh commits is often greater than quality control; especially in little corner cases like this that nevertheless contribute to the quality of the distribution. But that is a far cry from deliberately going out of our way to break compatibility by removing the dummy package prematurely. I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). Sounds like a bug to me. Could you be more verbose what you consider to be a bug? [ ] The fact that we don't regularily make test installations of sid packages on potato Regularily? Or ever? [ ] The fact that potato's bash has some bugs that sid's one does not. Do we need to use these features that would break potato's bash in install scripts? Used to be the case that one was careful and minimalistic in installation. Hmm. I'll be testing my packages out in a potato chroot to be sure. [ ] Something else. Breaking our traditional compatibility from the version before stable in to unstable (though perhaps that tradition has been broken as often as it has een observed of late). manoj -- I put instant coffee in a microwave and almost went back in time. Steven Wright Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Renaming a package
On Fri, 3 Oct 2003, Peter S Galbraith wrote: Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release? I think we should keep them by at least two stable releases, so that upgrades which skip exactly one stable release (for example, from potato to sarge) still work. After all, nobody could say that dummy packages take a lot of disk space in ftp-master or are difficult to maintain :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Fri, Oct 03, 2003 at 11:54:35PM -0400, Peter S Galbraith wrote: Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release? There is no official policy about that, but imho the answer to your question is yes. quoting a recent discussion on debian-devel: |-- | From: Andrew Suffield [EMAIL PROTECTED] | To: Debian Developers [EMAIL PROTECTED] | Subject: Re: Where are we now? (Was: Bits from the RM) | Message-ID: [EMAIL PROTECTED] | Date: Fri, 3 Oct 2003 03:52:30 +0100 | | On Thu, Oct 02, 2003 at 10:38:18PM +1000, Matthew Palmer wrote: | On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote: | be fun though. I'm planning to only support upgrades from potato and | woody. So that means i can remove all the cruft about upgrading from | | I was under the impression (don't ask me how; perhaps my mind came up with | it on it's own) that we only supported stable-stable+1 upgrades... | | Obviously not. Can anyone point me to a comprehensive rationale why not? | | Mindless optimism. If you try skipping a release on a box with a fair | amount of stuff installed, expect to spend all day fixing it. |-- I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Sat, 4 Oct 2003 10:03:11 +0200, Andreas Metzler [EMAIL PROTECTED] said: On Fri, Oct 03, 2003 at 11:54:35PM -0400, Peter S Galbraith wrote: Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release? There is no official policy about that, but imho the answer to your question is yes. Strange. In my opinion the answer is no. quoting a recent discussion on debian-devel: -- From: Andrew Suffield [EMAIL PROTECTED] To: Debian Developers [EMAIL PROTECTED] Subject: Re: Where are we now? (Was: Bits from the RM) Message-ID: [EMAIL PROTECTED] Date: Fri, 3 Oct 2003 03:52:30 +0100 On Thu, Oct 02, 2003 at 10:38:18PM +1000, Matthew Palmer wrote: On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote: be fun though. I'm planning to only support upgrades from potato and woody. So that means i can remove all the cruft about upgrading from I was under the impression (don't ask me how; perhaps my mind came up with it on it's own) that we only supported stable-stable+1 upgrades... Obviously not. Can anyone point me to a comprehensive rationale why not? Mindless optimism. If you try skipping a release on a box with a fair amount of stuff installed, expect to spend all day fixing it. -- The response should be to determine where these glitches lie and fix them, rather than just compromising on quality. I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). Sounds like a bug to me. manoj -- mophobia, n.: Fear of being verbally abused by a Mississippian. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
On Fri, 3 Oct 2003, Peter S Galbraith wrote: Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release? I think we should keep them by at least two stable releases, so that upgrades which skip exactly one stable release (for example, from potato to sarge) still work. After all, nobody could say that dummy packages take a lot of disk space in ftp-master or are difficult to maintain :-)
Re: Renaming a package
On Fri, Oct 03, 2003 at 11:54:35PM -0400, Peter S Galbraith wrote: Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release? There is no official policy about that, but imho the answer to your question is yes. quoting a recent discussion on debian-devel: |-- | From: Andrew Suffield [EMAIL PROTECTED] | To: Debian Developers debian-devel@lists.debian.org | Subject: Re: Where are we now? (Was: Bits from the RM) | Message-ID: [EMAIL PROTECTED] | Date: Fri, 3 Oct 2003 03:52:30 +0100 | | On Thu, Oct 02, 2003 at 10:38:18PM +1000, Matthew Palmer wrote: | On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote: | be fun though. I'm planning to only support upgrades from potato and | woody. So that means i can remove all the cruft about upgrading from | | I was under the impression (don't ask me how; perhaps my mind came up with | it on it's own) that we only supported stable-stable+1 upgrades... | | Obviously not. Can anyone point me to a comprehensive rationale why not? | | Mindless optimism. If you try skipping a release on a box with a fair | amount of stuff installed, expect to spend all day fixing it. |-- I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Renaming a package
On Sat, 4 Oct 2003 10:03:11 +0200, Andreas Metzler [EMAIL PROTECTED] said: On Fri, Oct 03, 2003 at 11:54:35PM -0400, Peter S Galbraith wrote: Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release? There is no official policy about that, but imho the answer to your question is yes. Strange. In my opinion the answer is no. quoting a recent discussion on debian-devel: -- From: Andrew Suffield [EMAIL PROTECTED] To: Debian Developers debian-devel@lists.debian.org Subject: Re: Where are we now? (Was: Bits from the RM) Message-ID: [EMAIL PROTECTED] Date: Fri, 3 Oct 2003 03:52:30 +0100 On Thu, Oct 02, 2003 at 10:38:18PM +1000, Matthew Palmer wrote: On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote: be fun though. I'm planning to only support upgrades from potato and woody. So that means i can remove all the cruft about upgrading from I was under the impression (don't ask me how; perhaps my mind came up with it on it's own) that we only supported stable-stable+1 upgrades... Obviously not. Can anyone point me to a comprehensive rationale why not? Mindless optimism. If you try skipping a release on a box with a fair amount of stuff installed, expect to spend all day fixing it. -- The response should be to determine where these glitches lie and fix them, rather than just compromising on quality. I would like to add to this experience that all the packages added after woody's release have never been tested whether their debconf-scripts run with potato's bash at all (see e.g. #209720). Sounds like a bug to me. manoj -- mophobia, n.: Fear of being verbally abused by a Mississippian. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
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: Renaming a package
On Fri, 3 Oct 2003, Peter S Galbraith wrote: In the upcoming version of the `emacs-goodies-el' source package, I want the following to happen to these bianry packages: `emacs-goodies-extra-el' - removed and contents merged into `emacs-goodies-el' `debbugs-el' - replaced by `debian-el' I did the following in the control file: Package: emacs-goodies-el Replaces: emacs-goodies-extra-el Conflicts: emacs-goodies-extra-el Provides: emacs-goodies-extra-el Package: debian-el Conflicts: debbugs-el Replaces: debbugs-el Provides: debbugs-el 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: # apt-get install dpkg-dev-el emacs-goodies-el Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: debian-el The following packages will be REMOVED: debbugs-el emacs-goodies-extra-el The following NEW packages will be installed: debian-el The following packages will be upgraded dpkg-dev-el emacs-goodies-el 2 packages upgraded, 1 newly installed, 2 to remove and 5 not upgraded. Need to get 480kB of archives. After unpacking 73.7kB will be freed. Do you want to continue? [Y/n] n Abort. Am I missing something? Maybe, the fact that APT tries to not remove any of your currently installed packages during an upgrade. There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. Then apt-get upgrade will actually upgrade all the packages. After the upgrade, dpkg --purge `deborphan` (which almost everybody usually does anyway) should remove the dummy packages. If you don't do that the user will have to read the release notes to see which packages he/she should upgrade by hand, but that would be a shame: the release notes are for things which we weren't able to fix before the release. My ideal of release notes is like this: -cut here-- To upgrade from woody to sarge, follow the usual procedure: apt-get update apt-get upgrade apt-get dist-upgrade -cut here-- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
On Fri, Oct 03, 2003 at 03:09:39PM -0400, Peter S Galbraith wrote: In the upcoming version of the `emacs-goodies-el' source package, I want the following to happen to these bianry packages: `emacs-goodies-extra-el' - removed and contents merged into `emacs-goodies-el' `debbugs-el' - replaced by `debian-el' I did the following in the control file: Package: emacs-goodies-el Replaces: emacs-goodies-extra-el Conflicts: emacs-goodies-extra-el Provides: emacs-goodies-extra-el [...] So it's holding back the two affected packages. However, installing them explicitely works: I do not claim to have grokked R/C/P completely but I think its main purpose is to tell dpkg/apt which package to remove if another package with identical R/C/P is _selected_ by the user. I think you'll need to use a dummy package: Package: emacs-goodies-el Replaces: emacs-goodies-extra-el Conflicts: emacs-goodies-extra-el (= version where emacs-goodies-extra-el had real content) Package: emacs-goodies-extra-el Depends: emacs-goodies-el Section: oldlibs Description: Dummy package for smooth upgrades cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
Santiago Vila [EMAIL PROTECTED] wrote: Maybe, the fact that APT tries to not remove any of your currently installed packages during an upgrade. kay, I was under the false impression this worked. There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Thanks! Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package
Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release? -- 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
Re: Renaming a package
On Fri, 3 Oct 2003, Peter S Galbraith wrote: In the upcoming version of the `emacs-goodies-el' source package, I want the following to happen to these bianry packages: `emacs-goodies-extra-el' - removed and contents merged into `emacs-goodies-el' `debbugs-el' - replaced by `debian-el' I did the following in the control file: Package: emacs-goodies-el Replaces: emacs-goodies-extra-el Conflicts: emacs-goodies-extra-el Provides: emacs-goodies-extra-el Package: debian-el Conflicts: debbugs-el Replaces: debbugs-el Provides: debbugs-el 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: # apt-get install dpkg-dev-el emacs-goodies-el Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: debian-el The following packages will be REMOVED: debbugs-el emacs-goodies-extra-el The following NEW packages will be installed: debian-el The following packages will be upgraded dpkg-dev-el emacs-goodies-el 2 packages upgraded, 1 newly installed, 2 to remove and 5 not upgraded. Need to get 480kB of archives. After unpacking 73.7kB will be freed. Do you want to continue? [Y/n] n Abort. Am I missing something? Maybe, the fact that APT tries to not remove any of your currently installed packages during an upgrade. There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. Then apt-get upgrade will actually upgrade all the packages. After the upgrade, dpkg --purge `deborphan` (which almost everybody usually does anyway) should remove the dummy packages. If you don't do that the user will have to read the release notes to see which packages he/she should upgrade by hand, but that would be a shame: the release notes are for things which we weren't able to fix before the release. My ideal of release notes is like this: -cut here-- To upgrade from woody to sarge, follow the usual procedure: apt-get update apt-get upgrade apt-get dist-upgrade -cut here-- 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.
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
On Fri, Oct 03, 2003 at 03:09:39PM -0400, Peter S Galbraith wrote: In the upcoming version of the `emacs-goodies-el' source package, I want the following to happen to these bianry packages: `emacs-goodies-extra-el' - removed and contents merged into `emacs-goodies-el' `debbugs-el' - replaced by `debian-el' I did the following in the control file: Package: emacs-goodies-el Replaces: emacs-goodies-extra-el Conflicts: emacs-goodies-extra-el Provides: emacs-goodies-extra-el [...] So it's holding back the two affected packages. However, installing them explicitely works: I do not claim to have grokked R/C/P completely but I think its main purpose is to tell dpkg/apt which package to remove if another package with identical R/C/P is _selected_ by the user. I think you'll need to use a dummy package: Package: emacs-goodies-el Replaces: emacs-goodies-extra-el Conflicts: emacs-goodies-extra-el (= version where emacs-goodies-extra-el had real content) Package: emacs-goodies-extra-el Depends: emacs-goodies-el Section: oldlibs Description: Dummy package for smooth upgrades cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Renaming a package
Santiago Vila [EMAIL PROTECTED] wrote: Maybe, the fact that APT tries to not remove any of your currently installed packages during an upgrade. kay, I was under the false impression this worked. There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Thanks! Peter
Re: Renaming a package
Peter S Galbraith [EMAIL PROTECTED] wrote: Santiago Vila [EMAIL PROTECTED] wrote: There is not a standard to make a package to disappear, but there is something you can do to ensure that apt-get upgrade works: Just make emacs-goodies-extra-el a dummy (empty) package which depends on emacs-goodies-el, and make debbugs-el a dummy package which depends on debian-el. Make them of extra priority and section oldlibs. Remove the conflicts, so that these packages are actually installed. I'm very glad I asked on this list. Many thanks! (makes me wonder if I should kill the extra package, considering it will live on anyway) Are we allowed to kill dummy packages after one stable release? If it were created now, I could simply remove it after sarge's release?
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: renaming a package
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 ? Friendly, Sven Luther -- 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 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 ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, 28 Jul 2002, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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, that depends on libglut3. I've done similar for glutg3-dev and libglut-dev. Does anyone have any comments or suggestions about this plan? Does it suck, is there a better way to do it and still provide a smooth upgrade, so developers depending on the glut libraries aren't shafted? Go ahead. Actually, there is not a better way using available dpkg fields. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, 28 Jul 2002 13:04:07 +1000, Jamie Wilkinson [EMAIL PROTECTED] wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. I prefer libglut3-dev . -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 her occasionally near suicidal sense of loyal self-sacrifice --- Luke Seubert, about what Rei Ayanami and Debian developers have in common -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, 28 Jul 2002, Oohara Yuuma wrote: On Sun, 28 Jul 2002 13:04:07 +1000, Jamie Wilkinson [EMAIL PROTECTED] wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. I prefer libglut3-dev . We should make versioned -dev (binary) packages the exception, not the norm. libglut-dev is better. Think about libglut3-dev, libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades much easier. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, Jul 28, 2002 at 04:34:54PM +0200, Santiago Vila wrote: We should make versioned -dev (binary) packages the exception, not the norm. libglut-dev is better. Think about libglut3-dev, libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades much easier. Except that this means the old source packages can't stay around in the archive, since libglut-dev is generated by both old and new. This makes transitions more difficult: libglut3 and libglut4 could still coexist on users' systems, but they could not both be in a distribution at the same time. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, 28 Jul 2002 16:34:54 +0200 (CEST), Santiago Vila [EMAIL PROTECTED] wrote: On Sun, 28 Jul 2002, Oohara Yuuma wrote: I prefer libglut3-dev . We should make versioned -dev (binary) packages the exception, not the norm. libglut-dev is better. Think about libglut3-dev, libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades much easier. 1. libfoo1 is compiled with libglut3 (that is, libglut-dev) 2. bar is compiled with libfoo1 3. libfoo1 is recompiled with libglut4 (that is, again, libglut-dev) 4. old bar does not work with new libfoo1 5. the maintainer of libfoo1 gets flamed because he/she is careless when using libglut-dev, though there is no good[1] way to specify a build-dependency to avoid this flame before libglut4 is released (that is, without knowing the version number of libglut-dev for libglut4) [1] Build-Depends: libglut-dev (= something) is suboptimal, and the fast way to get a FTBTS bug -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 her occasionally near suicidal sense of loyal self-sacrifice --- Luke Seubert, about what Rei Ayanami and Debian developers have in common -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
Colin Watson wrote: On Sun, Jul 28, 2002 at 04:34:54PM +0200, Santiago Vila wrote: We should make versioned -dev (binary) packages the exception, not the norm. libglut-dev is better. Think about libglut3-dev, libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades much easier. Except that this means the old source packages can't stay around in the archive, since libglut-dev is generated by both old and new. This makes transitions more difficult: libglut3 and libglut4 could still coexist on users' systems, but they could not both be in a distribution at the same time. AFAIK, katie supports that several packages generate the same binary package and the new one takes precedence; but even if this feature has been disabled, we can always repackage the old library so that it only generates the old library package, not the -dev one. By providing a single -dev package on each given distribution, we avoid the user the need to investigate about which one is the good one to be used. I think this is good and desirable for most libraries. Oohara Yuuma wrote: 1. libfoo1 is compiled with libglut3 (that is, libglut-dev) 2. bar is compiled with libfoo1 3. libfoo1 is recompiled with libglut4 (that is, again, libglut-dev) 4. old bar does not work with new libfoo1 5. the maintainer of libfoo1 gets flamed because he/she is careless when using libglut-dev, though there is no good[1] way to specify a build-dependency to avoid this flame before libglut4 is released (that is, without knowing the version number of libglut-dev for libglut4) Nobody should be flamed for not having a crystal ball... Build-Depends: libfoo-dev (= whatever) could be used here if needed (I mean, if a package has to be reuploaded using a versioned build-depends). Yes, this may happen. I never said a single -dev should be always better. There will be libraries for which a single -dev is a good idea and others for which it's not. Of course, libraries which do not keep enough backwards source-compatiblity across different releases are the typical case where a single -dev package does not help very much. But those libraries should be the exception too, not the norm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, Jul 28, 2002 at 01:04:07PM +1000, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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. Christophe that depends on libglut3. I've done similar for glutg3-dev and libglut-dev. Does anyone have any comments or suggestions about this plan? Does it suck, is there a better way to do it and still provide a smooth upgrade, so developers depending on the glut libraries aren't shafted? -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Christophe Barbé [EMAIL PROTECTED] GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Cats are intented to teach us that not everything in nature has a function. --Garrison Keillor msg06735/pgp0.pgp Description: PGP signature
Re: renaming a package
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. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
This one time, at band camp, christophe barbé wrote: On Sun, Jul 28, 2002 at 01:04:07PM +1000, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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. I did try to use Provides: but that didn't work, dpkg complained that glutg3 and libglut3 were conflicting: Package: libglut3 Conflicts: glutg3 (= 3.7-15) Replaces: glutg3 (= 3.7-15) Provides: glutg3 willow# dpkg -i ../libglut3_3.7-16_i386.deb ../libglut-dev_3.7-16_i386.deb Selecting previously deselected package libglut3. dpkg: considering removing glutg3 in favour of libglut3 ... dpkg: no, cannot remove glutg3 (--auto-deconfigure will help): billard-gl depends on glutg3 (= 3.7-2) glutg3 is to be removed. dpkg: regarding ../libglut3_3.7-16_i386.deb containing libglut3: libglut3 conflicts with glutg3 (= 3.7-15) glutg3 (version 3.7-15) is installed. dpkg: error processing ../libglut3_3.7-16_i386.deb (--install): conflicting packages - not installing libglut3 Selecting previously deselected package libglut-dev. dpkg: considering removing glutg3-dev in favour of libglut-dev ... dpkg: yes, will remove glutg3-dev in favour of libglut-dev. (Reading database ... 70338 files and directories currently installed.) Unpacking libglut-dev (from ../libglut-dev_3.7-16_i386.deb) ... dpkg: dependency problems prevent configuration of libglut-dev: libglut-dev depends on libglut3 (= 3.7-16); however: Package libglut3 is not installed. dpkg: error processing libglut-dev (--install): dependency problems - leaving unconfigured Errors were encountered while processing: ../libglut3_3.7-16_i386.deb libglut-dev -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
This one time, at band camp, Oohara Yuuma wrote: On Sun, 28 Jul 2002 13:04:07 +1000, Jamie Wilkinson [EMAIL PROTECTED] wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. I prefer libglut3-dev . I actually intend to make a libglut3-dev that provides libglut-dev, as per Junichi's libpkg-guide. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
This one time, at band camp, Santiago Vila wrote: On Sun, 28 Jul 2002, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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, that depends on libglut3. I've done similar for glutg3-dev and libglut-dev. Does anyone have any comments or suggestions about this plan? Does it suck, is there a better way to do it and still provide a smooth upgrade, so developers depending on the glut libraries aren't shafted? Go ahead. Actually, there is not a better way using available dpkg fields. Cool, thanks. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, 28 Jul 2002, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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, that depends on libglut3. I've done similar for glutg3-dev and libglut-dev. Does anyone have any comments or suggestions about this plan? Does it suck, is there a better way to do it and still provide a smooth upgrade, so developers depending on the glut libraries aren't shafted? Go ahead. Actually, there is not a better way using available dpkg fields. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, 28 Jul 2002 13:04:07 +1000, Jamie Wilkinson [EMAIL PROTECTED] wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. I prefer libglut3-dev . -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 her occasionally near suicidal sense of loyal self-sacrifice --- Luke Seubert, about what Rei Ayanami and Debian developers have in common -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, Jul 28, 2002 at 04:34:54PM +0200, Santiago Vila wrote: We should make versioned -dev (binary) packages the exception, not the norm. libglut-dev is better. Think about libglut3-dev, libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades much easier. Except that this means the old source packages can't stay around in the archive, since libglut-dev is generated by both old and new. This makes transitions more difficult: libglut3 and libglut4 could still coexist on users' systems, but they could not both be in a distribution at the same time. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, 28 Jul 2002 16:34:54 +0200 (CEST), Santiago Vila [EMAIL PROTECTED] wrote: On Sun, 28 Jul 2002, Oohara Yuuma wrote: I prefer libglut3-dev . We should make versioned -dev (binary) packages the exception, not the norm. libglut-dev is better. Think about libglut3-dev, libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades much easier. 1. libfoo1 is compiled with libglut3 (that is, libglut-dev) 2. bar is compiled with libfoo1 3. libfoo1 is recompiled with libglut4 (that is, again, libglut-dev) 4. old bar does not work with new libfoo1 5. the maintainer of libfoo1 gets flamed because he/she is careless when using libglut-dev, though there is no good[1] way to specify a build-dependency to avoid this flame before libglut4 is released (that is, without knowing the version number of libglut-dev for libglut4) [1] Build-Depends: libglut-dev (= something) is suboptimal, and the fast way to get a FTBTS bug -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 her occasionally near suicidal sense of loyal self-sacrifice --- Luke Seubert, about what Rei Ayanami and Debian developers have in common -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
Colin Watson wrote: On Sun, Jul 28, 2002 at 04:34:54PM +0200, Santiago Vila wrote: We should make versioned -dev (binary) packages the exception, not the norm. libglut-dev is better. Think about libglut3-dev, libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades much easier. Except that this means the old source packages can't stay around in the archive, since libglut-dev is generated by both old and new. This makes transitions more difficult: libglut3 and libglut4 could still coexist on users' systems, but they could not both be in a distribution at the same time. AFAIK, katie supports that several packages generate the same binary package and the new one takes precedence; but even if this feature has been disabled, we can always repackage the old library so that it only generates the old library package, not the -dev one. By providing a single -dev package on each given distribution, we avoid the user the need to investigate about which one is the good one to be used. I think this is good and desirable for most libraries. Oohara Yuuma wrote: 1. libfoo1 is compiled with libglut3 (that is, libglut-dev) 2. bar is compiled with libfoo1 3. libfoo1 is recompiled with libglut4 (that is, again, libglut-dev) 4. old bar does not work with new libfoo1 5. the maintainer of libfoo1 gets flamed because he/she is careless when using libglut-dev, though there is no good[1] way to specify a build-dependency to avoid this flame before libglut4 is released (that is, without knowing the version number of libglut-dev for libglut4) Nobody should be flamed for not having a crystal ball... Build-Depends: libfoo-dev (= whatever) could be used here if needed (I mean, if a package has to be reuploaded using a versioned build-depends). Yes, this may happen. I never said a single -dev should be always better. There will be libraries for which a single -dev is a good idea and others for which it's not. Of course, libraries which do not keep enough backwards source-compatiblity across different releases are the typical case where a single -dev package does not help very much. But those libraries should be the exception too, not the norm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Sun, Jul 28, 2002 at 01:04:07PM +1000, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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. Christophe that depends on libglut3. I've done similar for glutg3-dev and libglut-dev. Does anyone have any comments or suggestions about this plan? Does it suck, is there a better way to do it and still provide a smooth upgrade, so developers depending on the glut libraries aren't shafted? -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Christophe Barbé [EMAIL PROTECTED] GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Cats are intented to teach us that not everything in nature has a function. --Garrison Keillor pgpEVicXYvVKn.pgp Description: PGP signature
Re: renaming a package
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. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
This one time, at band camp, christophe barbé wrote: On Sun, Jul 28, 2002 at 01:04:07PM +1000, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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. I did try to use Provides: but that didn't work, dpkg complained that glutg3 and libglut3 were conflicting: Package: libglut3 Conflicts: glutg3 (= 3.7-15) Replaces: glutg3 (= 3.7-15) Provides: glutg3 willow# dpkg -i ../libglut3_3.7-16_i386.deb ../libglut-dev_3.7-16_i386.deb Selecting previously deselected package libglut3. dpkg: considering removing glutg3 in favour of libglut3 ... dpkg: no, cannot remove glutg3 (--auto-deconfigure will help): billard-gl depends on glutg3 (= 3.7-2) glutg3 is to be removed. dpkg: regarding ../libglut3_3.7-16_i386.deb containing libglut3: libglut3 conflicts with glutg3 (= 3.7-15) glutg3 (version 3.7-15) is installed. dpkg: error processing ../libglut3_3.7-16_i386.deb (--install): conflicting packages - not installing libglut3 Selecting previously deselected package libglut-dev. dpkg: considering removing glutg3-dev in favour of libglut-dev ... dpkg: yes, will remove glutg3-dev in favour of libglut-dev. (Reading database ... 70338 files and directories currently installed.) Unpacking libglut-dev (from ../libglut-dev_3.7-16_i386.deb) ... dpkg: dependency problems prevent configuration of libglut-dev: libglut-dev depends on libglut3 (= 3.7-16); however: Package libglut3 is not installed. dpkg: error processing libglut-dev (--install): dependency problems - leaving unconfigured Errors were encountered while processing: ../libglut3_3.7-16_i386.deb libglut-dev -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
This one time, at band camp, Oohara Yuuma wrote: On Sun, 28 Jul 2002 13:04:07 +1000, Jamie Wilkinson [EMAIL PROTECTED] wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. I prefer libglut3-dev . I actually intend to make a libglut3-dev that provides libglut-dev, as per Junichi's libpkg-guide. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
This one time, at band camp, Santiago Vila wrote: On Sun, 28 Jul 2002, Jamie Wilkinson wrote: I intend to rename the glut packages from glutg3 glutg3-dev to libglut3 libglut-dev to follow the convention for library package naming. 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, that depends on libglut3. I've done similar for glutg3-dev and libglut-dev. Does anyone have any comments or suggestions about this plan? Does it suck, is there a better way to do it and still provide a smooth upgrade, so developers depending on the glut libraries aren't shafted? Go ahead. Actually, there is not a better way using available dpkg fields. Cool, thanks. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming source package -- problems?
David Coe wrote: since it will still produce a 'wenglish' binary package, i assume upgrades won't be a problem, but what about the old sources? how do i get rid of them when i upload the new source package with its new name? File a bug on ftp.debian.org. I don't think they'll be deleted automatically. and will i cause other confusion? (bug tracking system is relatively clean, so I'm not worried there). No, there should be no other problems. -- see shy jo
