Bug#758312: closed by Michael Gilbert (Re: [pkg-wine-party] Bug#758312: wine-development: please provide an upgrade path)
Coin, wine-unstable was never in a stable release (or testing even), so there is no need for the inconvenience of transitional packages. I already told you i was aware of that, but did you read my BR? Aren't you happy to be able to upgrade your unstable test system / pbuilder / sbuild instead of reinstalling it from scratch every time or having to do dirty hacking? Many libraries have many upgrade cycles before the freeze and other maintainers handle a proper migration wether or not this will be the final version for the release or not. This ensure rdeps and maintainer's test systems can be upgraded without pain. Even you have rdeps such as playonlinux. You cannot expect people to follow you very specific ML and handle things manually each time you "feel like" to rename a package. I know there is nothing clearly stated in the policy about this, but this is how all key packages are handled and this has proved good for us all, so i really urge you to rethink about it (for the future). Regards. -- Marc Dequènes (Duck) pgp_rGHRbu8M5.pgp Description: PGP Digital Signature
Bug#758291: [pkg-wine-party] Bug#758312: wine-development: please provide an upgrade path
*Sorry, i sent accidentaly the previous message * Actually, the both wine's package in debian repository don't work correctly when you install the 32-bits and 64-bits package. The installation is fine but when you launch wine64, a 64-bits prefix is create but it's impossible to launch and install a 32-bits applications (like explained here http://wiki.winehq.org/Wine64 section "Building a shared WoW64 setup") I already explained to Michael how it's possible to use this shared WoW64 setup. libwine package amd64 *MUST* to contain all librairies present in "/usr/lib/x86_64-linux-gnu" + /usr/bin/wine64 file + /usr/bin/wine64-preloader file libwine package i386 *MUST* to contain all librairies present in "/usr/lib/i386-linux-gnu" + /usr/bin/wine file + /usr/bin/wine-preloader file wine package amd64 / i386 *MUST* to contain the rest of wine's files present in "/usr/bin" (like winegcc, winecfg etc...) *THE 64-BITS USERS NEED NECESSARILY LIBWINE AMD64 + I386 PACKAGES AND WINE AMD64 PACKAGE* 2014-08-17 19:13 GMT+02:00 LOMBARD Maxime : > Actually, the both wine's package in debian repository don't work > correctly when you install the 32-bits and 64-bits package. The > installation is fine but when you launch wine64, a 64-bits prefix is create > but it's impossible to launch and install a 32-bits applications (like > explained here http://wiki.winehq.org/Wine64 section "Building a shared > WoW64 setup") > > I already explain to Michael how it's possible to use this shared WoW64 > setup. To use it, a user needs libwine package amd64 + i386 and wine > package amd64. > libwine package amd 64 *MUST* to contain all librairies present in > "/usr/lib/x86_64-linux-gnu" + > > > 2014-08-17 17:00 GMT+02:00 jre : > > Hi >> >> On 08/17/2014 02:38 PM, LOMBARD Maxime wrote: >> > Make a difference between the stable and unstable version of wine can be >> > a good idea BUT only in the package's name and not in the application's >> > name. >> > >> > For me actually, it's very complicated and it will be more difficult to >> > resolv bug ... >> > Why you don't create the wine's package like from Ubuntu, it's more >> easy : >> > >> > *** Stable Wine's package *** >> > wine package which include all files installed in "/usr/bin" >> > libwine package which include all files installed in "/usr/lib/*/wine" >> > >> > *** Unstable Wine's package *** >> > wine-unstable package which include all files installed in "/usr/bin" >> > without suffixe >> > libwine-unstable package which include all files installed in >> > "/usr/lib/*/wine" without suffixe. >> > >> > And failed the both installations. Example, wine is in conflict with >> > wine-unstable and vice-versa. >> > If a user install wine-unstable package, it uninstall automatically wine >> > package. >> >> Well, this is not really related to #758312 since this one is indeed >> about the package names and the transition -unstable --> -development. >> >> Anyway; afaik it was a long standing goal to make both wine versions >> (including their 32bit and 64bit versions) coinstallable. This I would >> really like to see. >> Still I agree that working directly with the suffix'ed versions really >> is a pain and does not meet user's expectations. >> Therefore in bug #758291 ([wine-development] Please use Debian's >> alternative system) I requested/suggested an actual solution which imho >> should make us all happy. >> Without it I would tend to prefer your solution. >> >> I think we are finally quite close to actually get the wine packages >> that were planned for many painful years now (again a so huge thank you >> to Michael here). I hope to send a first patch to #758291 tomorrow which >> implements the alternative system at least for the -development packages. >> >> I CC'd that bug because I think discussing this topic is more >> appropriate there (or directly at the pkg-wine-party list). >> >> Greets >> jre >> >> >> >
Bug#758291: [pkg-wine-party] Bug#758312: wine-development: please provide an upgrade path
Actually, the both wine's package in debian repository don't work correctly when you install the 32-bits and 64-bits package. The installation is fine but when you launch wine64, a 64-bits prefix is create but it's impossible to launch and install a 32-bits applications (like explained here http://wiki.winehq.org/Wine64 section "Building a shared WoW64 setup") I already explain to Michael how it's possible to use this shared WoW64 setup. To use it, a user needs libwine package amd64 + i386 and wine package amd64. libwine package amd 64 *MUST* to contain all librairies present in "/usr/lib/x86_64-linux-gnu" + 2014-08-17 17:00 GMT+02:00 jre : > Hi > > On 08/17/2014 02:38 PM, LOMBARD Maxime wrote: > > Make a difference between the stable and unstable version of wine can be > > a good idea BUT only in the package's name and not in the application's > > name. > > > > For me actually, it's very complicated and it will be more difficult to > > resolv bug ... > > Why you don't create the wine's package like from Ubuntu, it's more easy > : > > > > *** Stable Wine's package *** > > wine package which include all files installed in "/usr/bin" > > libwine package which include all files installed in "/usr/lib/*/wine" > > > > *** Unstable Wine's package *** > > wine-unstable package which include all files installed in "/usr/bin" > > without suffixe > > libwine-unstable package which include all files installed in > > "/usr/lib/*/wine" without suffixe. > > > > And failed the both installations. Example, wine is in conflict with > > wine-unstable and vice-versa. > > If a user install wine-unstable package, it uninstall automatically wine > > package. > > Well, this is not really related to #758312 since this one is indeed > about the package names and the transition -unstable --> -development. > > Anyway; afaik it was a long standing goal to make both wine versions > (including their 32bit and 64bit versions) coinstallable. This I would > really like to see. > Still I agree that working directly with the suffix'ed versions really > is a pain and does not meet user's expectations. > Therefore in bug #758291 ([wine-development] Please use Debian's > alternative system) I requested/suggested an actual solution which imho > should make us all happy. > Without it I would tend to prefer your solution. > > I think we are finally quite close to actually get the wine packages > that were planned for many painful years now (again a so huge thank you > to Michael here). I hope to send a first patch to #758291 tomorrow which > implements the alternative system at least for the -development packages. > > I CC'd that bug because I think discussing this topic is more > appropriate there (or directly at the pkg-wine-party list). > > Greets > jre > > >
Bug#758291: [pkg-wine-party] Bug#758312: wine-development: please provide an upgrade path
Hi On 08/17/2014 02:38 PM, LOMBARD Maxime wrote: > Make a difference between the stable and unstable version of wine can be > a good idea BUT only in the package's name and not in the application's > name. > > For me actually, it's very complicated and it will be more difficult to > resolv bug ... > Why you don't create the wine's package like from Ubuntu, it's more easy : > > *** Stable Wine's package *** > wine package which include all files installed in "/usr/bin" > libwine package which include all files installed in "/usr/lib/*/wine" > > *** Unstable Wine's package *** > wine-unstable package which include all files installed in "/usr/bin" > without suffixe > libwine-unstable package which include all files installed in > "/usr/lib/*/wine" without suffixe. > > And failed the both installations. Example, wine is in conflict with > wine-unstable and vice-versa. > If a user install wine-unstable package, it uninstall automatically wine > package. Well, this is not really related to #758312 since this one is indeed about the package names and the transition -unstable --> -development. Anyway; afaik it was a long standing goal to make both wine versions (including their 32bit and 64bit versions) coinstallable. This I would really like to see. Still I agree that working directly with the suffix'ed versions really is a pain and does not meet user's expectations. Therefore in bug #758291 ([wine-development] Please use Debian's alternative system) I requested/suggested an actual solution which imho should make us all happy. Without it I would tend to prefer your solution. I think we are finally quite close to actually get the wine packages that were planned for many painful years now (again a so huge thank you to Michael here). I hope to send a first patch to #758291 tomorrow which implements the alternative system at least for the -development packages. I CC'd that bug because I think discussing this topic is more appropriate there (or directly at the pkg-wine-party list). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758312: [pkg-wine-party] Bug#758312: wine-development: please provide an upgrade path
Hi, On 08/16/2014 07:57 PM, Marc Dequènes (Duck) wrote: > I have no idea why you renamed wine-unstable into wine-development, This was announced and discussed here: http://lists.alioth.debian.org/pipermail/pkg-wine-party/2014-April/003804.html Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758312: wine-development: please provide an upgrade path
Hi, Make a difference between the stable and unstable version of wine can be a good idea BUT only in the package's name and not in the application's name. For me actually, it's very complicated and it will be more difficult to resolv bug ... Why you don't create the wine's package like from Ubuntu, it's more easy : *** Stable Wine's package *** wine package which include all files installed in "/usr/bin" libwine package which include all files installed in "/usr/lib/*/wine" *** Unstable Wine's package *** wine-unstable package which include all files installed in "/usr/bin" without suffixe libwine-unstable package which include all files installed in "/usr/lib/*/wine" without suffixe. And failed the both installations. Example, wine is in conflict with wine-unstable and vice-versa. If a user install wine-unstable package, it uninstall automatically wine package. @Michael : I never use your package, it's a very useless (my opinion). I completly modified your "debian" folder to create my own package.
Bug#758312: wine-development: please provide an upgrade path
Source: wine-development Severity: normal Coin, I have no idea why you renamed wine-unstable into wine-development, but since the former existed during a significant time in unstable you need to provide an upgrade path. How are your fellow developpers and testers supposed to know about it ? I perfectly understand wine-unstable is not in stable so there is no need for it in the next release, but you can simply drop it just before the release. That's how many other packages do and that greatly simplifies our lives. Regards. -- Marc Dequènes (Duck) pgpuLPrs5wpXH.pgp Description: PGP Digital Signature