Bug#620065: fixed in libimobiledevice 1.1.0-3
On Tue, 03 May 2011, Julien Lavergne wrote: Btw, I understood that I need to keep the Replaces: libimobiledevice2 in libimobiledevice2, right ? Because without it, there will be a error when the upgrade will happen ? Hum, typo I guess. You need Replaces: libimobiledevice1 in libimobiledevice2. In the end, it should be : libimobiledevice1 Replaces: libimobiledevice2 libimobiledevice2 Replaces: libimobiledevice1 Let me know if I miss something. In fact only the second one is really needed. dpkg deals correctly with upgrade of libimobiledevice1. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Le Wednesday 04 May 2011 à 07:58 +0200, Raphael Hertzog a écrit : In fact only the second one is really needed. dpkg deals correctly with upgrade of libimobiledevice1. Ok, thank you for the clarification :) The update is in progress. Regards, Julien Lavergne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
On Fri, 22 Apr 2011, Julien Lavergne wrote: Le Monday 18 April 2011 à 21:27 +0200, Raphael Hertzog a écrit : Hi, First of all, I wanted to suggest to drop the Conflicts and just keep the Replaces. The Replaces is enough, the only problem is that the FDI file will be lost if libimobiledevice2 is removed while some application still use libimobiledevice1 (the other cases are correctly handled by dpkg whatever the order of installation of the packages). Ok, It sounds reasonable. I'll try to update it this week-end, but feel free to NMU it if it's an emergency. It looks like this did not happen... can I help by sponsoring an update? The plan is drop the Conflicts/Replaces in libimobiledevice1 and add a Replaces: libimobiledevice1 in libimobiledevice2. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Le Tuesday 03 May 2011 à 08:14 +0200, Raphael Hertzog a écrit : It looks like this did not happen... can I help by sponsoring an update? The plan is drop the Conflicts/Replaces in libimobiledevice1 and add a Replaces: libimobiledevice1 in libimobiledevice2. The changes was made for libimobiledevice2, I need to do the change for libimobiledevice1 (but should happen shortly). Btw, I understood that I need to keep the Replaces: libimobiledevice2 in libimobiledevice2, right ? Because without it, there will be a error when the upgrade will happen ? In the end, it should be : libimobiledevice1 Replaces: libimobiledevice2 libimobiledevice2 Replaces: libimobiledevice1 Let me know if I miss something. Regards, Julien Lavergne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Le 22 avr. 2011 à 08:07, Raphael Hertzog hert...@debian.org a écrit : On Fri, 22 Apr 2011, Julien Lavergne wrote: Le Monday 18 April 2011 à 21:27 +0200, Raphael Hertzog a écrit : Hi, First of all, I wanted to suggest to drop the Conflicts and just keep the Replaces. The Replaces is enough, the only problem is that the FDI file will be lost if libimobiledevice2 is removed while some application still use libimobiledevice1 (the other cases are correctly handled by dpkg whatever the order of installation of the packages). Ok, It sounds reasonable. I'll try to update it this week-end, but feel free to NMU it if it's an emergency. This WE should be fine, thanks. Those uploads will be needed anyway, as I think libimobiledevice2 is/will not be API-compatible with libimobiledevice1. So, could be a moot point. Julien (Lavergne), do you know if this is the case? For now, only new API was added, but as they declared the API not stable, we can't be sure what is going to change. To be safe, I prefer to assume that the API can change, that's why it should stay in experimental until 1.2.0 is released. The stable release of gvfs depends on this new API apparently due to this new feature: https://bugzilla.gnome.org/show_bug.cgi?id=636132 Do you know when upstream plans to release 1.2.0? No release date, unfortunately. The devs are working on it, but as there are not many, the policy is When it's done. Last time I check, the progress was good, and not so far from the release. Regards, Julien Lavergne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
On Fri, 22 Apr 2011, Julien Lavergne wrote: Le Monday 18 April 2011 à 21:27 +0200, Raphael Hertzog a écrit : Hi, First of all, I wanted to suggest to drop the Conflicts and just keep the Replaces. The Replaces is enough, the only problem is that the FDI file will be lost if libimobiledevice2 is removed while some application still use libimobiledevice1 (the other cases are correctly handled by dpkg whatever the order of installation of the packages). Ok, It sounds reasonable. I'll try to update it this week-end, but feel free to NMU it if it's an emergency. This WE should be fine, thanks. Those uploads will be needed anyway, as I think libimobiledevice2 is/will not be API-compatible with libimobiledevice1. So, could be a moot point. Julien (Lavergne), do you know if this is the case? For now, only new API was added, but as they declared the API not stable, we can't be sure what is going to change. To be safe, I prefer to assume that the API can change, that's why it should stay in experimental until 1.2.0 is released. The stable release of gvfs depends on this new API apparently due to this new feature: https://bugzilla.gnome.org/show_bug.cgi?id=636132 Do you know when upstream plans to release 1.2.0? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
On Tue, 19 Apr 2011, Julien BLACHE wrote: Depending on that, even staging a transition in experimental doesn't make sense at this point. Basically we're screwed until upstream is done breaking things :) Ok, but can we at least get rid of the Conflicts in the mean time and use only a Replaces so that people can _use_ what's in experimental? If experimental is not even installable, it's not very useful at all. Thanks in advance. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Le Monday 18 April 2011 à 21:27 +0200, Raphael Hertzog a écrit : Hi, First of all, I wanted to suggest to drop the Conflicts and just keep the Replaces. The Replaces is enough, the only problem is that the FDI file will be lost if libimobiledevice2 is removed while some application still use libimobiledevice1 (the other cases are correctly handled by dpkg whatever the order of installation of the packages). Ok, It sounds reasonable. I'll try to update it this week-end, but feel free to NMU it if it's an emergency. Those uploads will be needed anyway, as I think libimobiledevice2 is/will not be API-compatible with libimobiledevice1. So, could be a moot point. Julien (Lavergne), do you know if this is the case? For now, only new API was added, but as they declared the API not stable, we can't be sure what is going to change. To be safe, I prefer to assume that the API can change, that's why it should stay in experimental until 1.2.0 is released. Regards, Julien Lavergne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Raphael Hertzog hert...@debian.org wrote: Hi, The multiarch requirements aren't relevant here, as the file is installed in /etc and is identical regardless of the architecture the package is built for. So the overlap will be handled by dpkg. That is, if the wiki page is accurate. The file is in /usr/share not /etc, but you're right, dpkg will cope with it. Sorry, brainfart. For some reason FDI files are in /etc in my mind, I blame Xorg for that :) Those uploads will be needed anyway, as I think libimobiledevice2 is/will not be API-compatible with libimobiledevice1. So, could be a moot point. Julien (Lavergne), do you know if this is the case? My recollection of the events is that the GNOME maintainers asked for the new libimobiledevice in experimental because they needed it, but at the same time the API/ABI isn't final yet. It's still expected to evolve and cleanups should happen at some point too. So it went to experimental both because it was needed there and because it belonged there. Julien will set the record straight if I'm wrong and can update us on the exact upstream status. Depending on that, even staging a transition in experimental doesn't make sense at this point. Basically we're screwed until upstream is done breaking things :) JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
reopen 620065 thanks On Tue, 12 Apr 2011, Julien Lavergne wrote: libimobiledevice (1.1.0-3) experimental; urgency=low . * debian/control: - Add Conlicts / Replaces on libimobiledevice1 and libimobiledevice0, since they provide the same fdi file. LP: #753015, Closes: #620065 This is not the proper solution. Because of this libimobiledevice1 and libimobiledevice2 are not co-installable and they need to be coinstallable to ensure a proper transition from one to the other. If the FDI file can be shared between both versions of the library (which I guess), then you should put it in a -common package and have that package Replaces the old version of libimobiledevice1 / libimobiledevice2 that provide this file. Of course you should add a dependency on the -common package. If the FDI file can't be shared, they you must discuss with upstream to find a good solution. Right now anything that depends on libimobiledevice2 in uninstallable until all packages depending on libimobiledevice1 have been updated. This is a painful transition and it affects GNOME3. I can review and sponsor you for this specific fix if you want. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Raphael Hertzog hert...@debian.org wrote: If the FDI file can be shared between both versions of the library (which I guess), then you should put it in a -common package and have that package Replaces the old version of libimobiledevice1 / libimobiledevice2 that provide this file. Of course you should add a dependency on the -common package. I NACKed that because the package would be ridiculously small and this is/has been a cause of REJECT. Moreover the transition isn't as big as you seem to imply, there aren't a lot of packages outside the GNOME world using libimobiledevice just yet. This is pretty self-contained and can be handled together with GNOME. Finally, there's also the option of dropping the FDI file entirely, given we plan to get rid of HAL sooner rather than later. I'm not sure about the status of non-Linux architectures wrt libimobiledevice, so the lack of HAL support there may be a moot point. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
On Mon, 18 Apr 2011, Julien BLACHE wrote: I NACKed that because the package would be ridiculously small and this is/has been a cause of REJECT. Well with multiarch shortly ahead of us it's more and more important for lib* packages to have only the library files and not any sort of support file. So there will be other similar cases and I doubt the ftpmasters will reject them. Their concerns should not forbid us to do the right thing in terms of library packaging. Moreover the transition isn't as big as you seem to imply, there aren't a lot of packages outside the GNOME world using libimobiledevice just yet. This is pretty self-contained and can be handled together with GNOME. Well, we can't bin-nmu in experimental so it means fake source upload in experimental with increased build-dep just to be able to provide updated binaries of all packages using libimobiledevice1... That doesn't seem good. Finally, there's also the option of dropping the FDI file entirely, given we plan to get rid of HAL sooner rather than later. I'm not sure about the status of non-Linux architectures wrt libimobiledevice, so the lack of HAL support there may be a moot point. Several of the reverse build-dependencies of libimobiledevice-dev use it with an architecture restriction [linux-any] but not all of them. I don't know how important that FDI file is in the grand scheme of the library. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Raphael Hertzog hert...@debian.org wrote: I NACKed that because the package would be ridiculously small and this is/has been a cause of REJECT. Well with multiarch shortly ahead of us it's more and more important for lib* packages to have only the library files and not any sort of support file. The multiarch requirements aren't relevant here, as the file is installed in /etc and is identical regardless of the architecture the package is built for. So the overlap will be handled by dpkg. That is, if the wiki page is accurate. So there will be other similar cases and I doubt the ftpmasters will reject them. Their concerns should not forbid us to do the right thing in terms of library packaging. Can you get a statement from them on that? Thanks. Well, we can't bin-nmu in experimental so it means fake source upload in experimental with increased build-dep just to be able to provide updated binaries of all packages using libimobiledevice1... Those uploads will be needed anyway, as I think libimobiledevice2 is/will not be API-compatible with libimobiledevice1. So, could be a moot point. Finally, there's also the option of dropping the FDI file entirely, given we plan to get rid of HAL sooner rather than later. I'm not sure about the status of non-Linux architectures wrt libimobiledevice, so the lack of HAL support there may be a moot point. Several of the reverse build-dependencies of libimobiledevice-dev use it with an architecture restriction [linux-any] but not all of them. I don't know how important that FDI file is in the grand scheme of the library. That's a question for Julien (the other one - why yes, we're everywhere). JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
On 04/18/2011 07:18 PM, Raphael Hertzog wrote: Well, we can't bin-nmu in experimental oh. yes, we can. -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Hi, So there will be other similar cases and I doubt the ftpmasters will reject them. Their concerns should not forbid us to do the right thing in terms of library packaging. Another argument against this solution was the need for the package to go twice in NEW (1 with the creation of the -common binary, 1 when it will be dropped with HAL support), x2 because there are 2 different versions in unstable and experimental. Finally, there's also the option of dropping the FDI file entirely, given we plan to get rid of HAL sooner rather than later. I'm not sure about the status of non-Linux architectures wrt libimobiledevice, so the lack of HAL support there may be a moot point. Several of the reverse build-dependencies of libimobiledevice-dev use it with an architecture restriction [linux-any] but not all of them. I don't know how important that FDI file is in the grand scheme of the library. The only reason is to add support for Amarok which still depends on HAL (see bug #615107). If Amarok don't need it anymore, the FDI can be dropped completely. but, I'm still ensure when / if this will be done, I can't find the proper bug report about the removal of HAL in Amarok. My only information are from this : http://bugs.kde.org/show_bug.cgi?id=184744 I had the hope that this will come fast enough to not stay in this situation too long. Regards, Julien Lavergne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: fixed in libimobiledevice 1.1.0-3
Hi, First of all, I wanted to suggest to drop the Conflicts and just keep the Replaces. The Replaces is enough, the only problem is that the FDI file will be lost if libimobiledevice2 is removed while some application still use libimobiledevice1 (the other cases are correctly handled by dpkg whatever the order of installation of the packages). It's really not a big problem and much less problematic than the non-coinstallability of both libraries. And as I understand it's temporary anyway. On Mon, 18 Apr 2011, Julien BLACHE wrote: The multiarch requirements aren't relevant here, as the file is installed in /etc and is identical regardless of the architecture the package is built for. So the overlap will be handled by dpkg. That is, if the wiki page is accurate. The file is in /usr/share not /etc, but you're right, dpkg will cope with it. Well, we can't bin-nmu in experimental so it means fake source upload in experimental with increased build-dep just to be able to provide updated binaries of all packages using libimobiledevice1... Those uploads will be needed anyway, as I think libimobiledevice2 is/will not be API-compatible with libimobiledevice1. So, could be a moot point. Julien (Lavergne), do you know if this is the case? If yes, can you arrange with the reverse build-dependencies to prepare the transition in experimental? On Mon, 18 Apr 2011, Mehdi Dogguy wrote: On 04/18/2011 07:18 PM, Raphael Hertzog wrote: Well, we can't bin-nmu in experimental oh. yes, we can. I know we can but the bin-nmus won't use the updated libimobiledevice-dev from experimental unless the build-dependencies are updated to require it. Thus a bin-nmu is not enough. On Mon, 18 Apr 2011, Julien Lavergne wrote: Another argument against this solution was the need for the package to go twice in NEW (1 with the creation of the -common binary, 1 when it will be dropped with HAL support), x2 because there are 2 different versions in unstable and experimental. OK, then please just keep the Replaces and drop the Conflicts. It will do the right thing for all people except those who might downgrade apps using libimobiledevice from versions using libimobiledevice2 to versions using libimobiledevice1. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620065: closed by Julien Lavergne julien.laver...@gmail.com (Bug#620065: fixed in libimobiledevice 1.1.0-3)
On 12/04/2011 18:21, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the libimobiledevice2 package: #620065: libimobiledevice2: file conflict with libimobiledevice1 It has been closed by Julien Lavergne julien.laver...@gmail.com. Unless your plan is to force packages depending on libimobiledevice1 to migrate to libimobiledevice2, conflicting with libimobiledevice1 is not the solution ! Removing libimobiledevice1 makes apt remove those packages. Maybe you need a *-common package to put your fdi files to, or if there are too few files concerned, simply rename them to avoid conflicts. Regards, Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
