Re: Recommended upgrade procedure for >1 release upgrades

On 11/22/2016 06:41 PM, Kalev Lember wrote: > On 11/22/2016 04:44 PM, Kamil Paral wrote: >>> OK, so we have two cases here: >>> >>> 1) gnome-software as is currently in F23 and F24 >>> >>> 2) gnome-software future releases >>> >>> For (1), the version of gnome-software in F23 and F24 currently

Re: Recommended upgrade procedure for >1 release upgrades

On 11/22/2016 04:44 PM, Kamil Paral wrote: >> OK, so we have two cases here: >> >> 1) gnome-software as is currently in F23 and F24 >> >> 2) gnome-software future releases >> >> For (1), the version of gnome-software in F23 and F24 currently doesn't >> have the UI in place to allow choosing which

Re: Recommended upgrade procedure for >1 release upgrades

On Mon, Nov 21, 2016 at 4:54 AM, Gerd Hoffmann wrote: > On Sa, 2016-11-19 at 08:56 +0100, Kevin Kofler wrote: >> Adam Williamson wrote: >> > I think I've proposed at least once that we make Obsoletes: for retired >> > packages mandatory. My last proposal currently seems to be

Re: Recommended upgrade procedure for >1 release upgrades

> OK, so we have two cases here: > > 1) gnome-software as is currently in F23 and F24 > > 2) gnome-software future releases > > For (1), the version of gnome-software in F23 and F24 currently doesn't > have the UI in place to allow choosing which version to upgrade to, so > gnome-software needs

Re: Recommended upgrade procedure for >1 release upgrades

Gerd Hoffmann wrote: > That is a non-trivial effort though. We would have to put the major > shared library version into package names, simliar to debian. No. When I say "packages that still work", not having broken dependencies is included in that. If they require an old soname, they no longer

Re: Recommended upgrade procedure for >1 release upgrades

On Sa, 2016-11-19 at 08:56 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > I think I've proposed at least once that we make Obsoletes: for retired > > packages mandatory. My last proposal currently seems to be assigned to > > tibbs. > > IMHO, forcefully removing packages that still work

Re: Recommended upgrade procedure for >1 release upgrades

On 19/11/16 08:56, Kevin Kofler wrote: Adam Williamson wrote: I think I've proposed at least once that we make Obsoletes: for retired packages mandatory. My last proposal currently seems to be assigned to tibbs. IMHO, forcefully removing packages that still work is a major disservice to our

Re: Recommended upgrade procedure for >1 release upgrades

Adam Williamson wrote: > I think I've proposed at least once that we make Obsoletes: for retired > packages mandatory. My last proposal currently seems to be assigned to > tibbs. IMHO, forcefully removing packages that still work is a major disservice to our users and should never be done.

Re: Recommended upgrade procedure for >1 release upgrades

On 2016-11-18 10:13 AM, Kalev Lember wrote: I don't think it would make upgrades less problematic because both dnf and gnome-software can already remove problematic packages without needing obsoletes. This isn't entirely true. It's true in straightforward cases, but there are complex cases

Re: Recommended upgrade procedure for >1 release upgrades

On Fri, Nov 18, 2016 at 07:58:14PM +0100, Kalev Lember wrote: > As for (2), I guess we should do the same as (1) but just allow the user > to choose the N+1 release as well in addition to N+2. I'd rather just always show the latest and tell people who have a special need to just go up one release

Re: Recommended upgrade procedure for >1 release upgrades

On 11/17/2016 07:26 PM, Adam Williamson wrote: > Hi, folks! > > While looking into an issue with how GNOME Software decides which > release to offer an upgrade to when there's more than one plausible > candidate, I noticed something interesting: we do not actually have a > policy on what we

Re: Recommended upgrade procedure for >1 release upgrades

On Fri, Nov 18, 2016 at 07:19:20PM +0100, Kalev Lember wrote: > There's a plan, but I don't think anyone is currently actively working > on this. I may look into this for F26, but not promising anything right now. I would really appreciate it if you can prioritize this. -- Matthew Miller

Re: Recommended upgrade procedure for >1 release upgrades

On 11/18/2016 06:03 PM, Adam Williamson wrote: > On 2016-11-18 08:30 AM, Ralf Corsepius wrote: >> Actually, I am inclined to believe only packages which are replaced by >> others within Fedora or are definitely dead can be obsoleted. Package >> which a just being retired for current/temporary lack

Re: Recommended upgrade procedure for >1 release upgrades

On 11/18/2016 02:50 PM, Stephen Gallagher wrote: > On 11/18/2016 07:07 AM, Marcin Juszkiewicz wrote: >> W dniu 18.11.2016 o 12:49, Michael Catanzaro pisze: >>> On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote: but GNOME Software use dnf-plugin-system-upgrade ? if yes , since then

Re: Recommended upgrade procedure for >1 release upgrades

On 2016-11-18 09:33 AM, Ralf Corsepius wrote: On 11/18/2016 06:08 PM, Adam Williamson wrote: On 2016-11-18 09:03 AM, Adam Williamson wrote: In fact, now I think about it for two seconds, the 'fedora-obsolete-packages' package can fulfill this role perfectly well. If we make it a policy that

Re: Recommended upgrade procedure for >1 release upgrades

On 11/18/2016 06:08 PM, Adam Williamson wrote: On 2016-11-18 09:03 AM, Adam Williamson wrote: In fact, now I think about it for two seconds, the 'fedora-obsolete-packages' package can fulfill this role perfectly well. If we make it a policy that all packages which are retired but not

Re: Recommended upgrade procedure for >1 release upgrades

> "AW" == Adam Williamson writes: AW> Meh, I disagree. It a reasonable point, but there were strong opinions against forced removal of packages in the manner you propose. This did go through FESCo as well. AW> Personally, though, I think any non-maintained

Re: Recommended upgrade procedure for >1 release upgrades

On Fri, Nov 18, 2016 at 08:48:20AM -0500, Stephen Gallagher wrote: > On 11/18/2016 01:02 AM, Sérgio Basto wrote: > > On Qui, 2016-11-17 at 21:04 +0100, Christian Dersch wrote: > >> > >> On 11/17/2016 09:01 PM, Luya Tshimbalanga wrote: > >>> Why not using a similar scheme from Libre Office [1]

Re: Recommended upgrade procedure for >1 release upgrades

On 2016-11-18 09:03 AM, Adam Williamson wrote: I guess one tweak I would be okay with would be a sort of weaker-Obsoletes mechanism: some kind of field that provides a hint to package managers that by default it's OK for the packaging system to remove a given package if it's blocking another

Re: Recommended upgrade procedure for >1 release upgrades

On 2016-11-18 08:30 AM, Ralf Corsepius wrote: Actually, I am inclined to believe only packages which are replaced by others within Fedora or are definitely dead can be obsoleted. Package which a just being retired for current/temporary lack interest/maintainer should not be obsoleted. I

Re: Recommended upgrade procedure for >1 release upgrades

On 2016-11-18 08:38 AM, Jason L Tibbitts III wrote: I don't recall anything about _forcing_ retired packages to be obsoleted. The current rules just say that you must do so if allowing the package to continue to exist would cause dependency issues. Forcing the removal of packages from systems

Re: Recommended upgrade procedure for >1 release upgrades

> "AW" == Adam Williamson writes: AW> (Interestingly, there is actually a way to solve this AW> *retroactively*: the other week I was kicking around the idea of AW> setting up a third-party repo containing a single package named AW> fedora-obsoletes which just

Re: Recommended upgrade procedure for >1 release upgrades

On 11/18/2016 05:16 PM, Adam Williamson wrote: (Interestingly, there is actually a way to solve this *retroactively*: the other week I was kicking around the idea of setting up a third-party repo containing a single package named fedora-obsoletes which just contains a bunch of obsoletes for

Re: Recommended upgrade procedure for >1 release upgrades

On 2016-11-18 01:03 AM, Miroslav Suchý wrote: Fedora N has: xorg-drivers-7.5 which requires xorg-drivers-foo, xorg-drivers-bar xorg-drivers-foo requires xorg-drivers = 7.5 xorg-drivers-bar requires xorg-drivers = 7.5 Fedora N+1 has: xorg-drivers-7.7 which requires xorg-drivers-foo

Re: Recommended upgrade procedure for >1 release upgrades

On 18/11/16 05:50, Stephen Gallagher wrote: GNOME Software uses PackageKit and both PackageKit and DNF these days use the same underlying dependency resolvers. So they're a lot closer than they used to be. Thanks. ___ devel mailing list --

Re: Recommended upgrade procedure for >1 release upgrades

On 11/18/2016 07:07 AM, Marcin Juszkiewicz wrote: > W dniu 18.11.2016 o 12:49, Michael Catanzaro pisze: >> On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote: >>> but GNOME Software use dnf-plugin-system-upgrade ? if yes , since >>> then >>> we have dnf-plugin-system-upgrade should be safe

Re: Recommended upgrade procedure for >1 release upgrades

On 11/18/2016 01:02 AM, Sérgio Basto wrote: > On Qui, 2016-11-17 at 21:04 +0100, Christian Dersch wrote: >> >> On 11/17/2016 09:01 PM, Luya Tshimbalanga wrote: >>> Why not using a similar scheme from Libre Office [1] where Fedora >>> 25 is >>> the more recent version while Fedora 24 is more

Re: Recommended upgrade procedure for >1 release upgrades

I think N+2 updates are barely done pre release by users out there, so issues will rarely be noted before final (F25 final in this case) lands. N+1 updates happen quite often during N+1 alpha and beta phase, thus they'll probably see more testing and should be recommended. OpenQA is fine, but

Re: Recommended upgrade procedure for >1 release upgrades

W dniu 18.11.2016 o 12:49, Michael Catanzaro pisze: > On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote: >> but GNOME Software use dnf-plugin-system-upgrade ? if yes , since >> then >> we have dnf-plugin-system-upgrade should be safe offer ii > > No, GNOME Software does not use dnf and never

Re: Recommended upgrade procedure for >1 release upgrades

On Fri, 2016-11-18 at 10:03 +0100, Miroslav Suchý wrote: > The example of this issue: > > Fedora N has: >    xorg-drivers-7.5 which requires xorg-drivers-foo, xorg-drivers-bar >    xorg-drivers-foo requires xorg-drivers = 7.5 >    xorg-drivers-bar requires xorg-drivers = 7.5 > > Fedora N+1 has:

Re: Recommended upgrade procedure for >1 release upgrades

On Fri, 2016-11-18 at 05:37 +, Sérgio Basto wrote: > but GNOME Software use dnf-plugin-system-upgrade ? if yes , since > then > we have dnf-plugin-system-upgrade should be safe offer ii  No, GNOME Software does not use dnf and never will. Michael

Re: Recommended upgrade procedure for >1 release upgrades

Dne 17.11.2016 v 19:26 Adam Williamson napsal(a): You'll notice we don't explicitly specify *how* you should do this. That is, if you're currently running Fedora 23, and you want to upgrade to Fedora 25 next week, are you supposed to: i) Upgrade to Fedora 24 first, then from Fedora 24 to Fedora

Re: Recommended upgrade procedure for >1 release upgrades

On Qui, 2016-11-17 at 21:04 +0100, Christian Dersch wrote: > > On 11/17/2016 09:01 PM, Luya Tshimbalanga wrote: > > > > On 17/11/16 10:26 AM, Adam Williamson wrote: > > > > > > Hi, folks! > > > > > > While looking into an issue with how GNOME Software decides which > > > release to offer an

Re: Recommended upgrade procedure for >1 release upgrades

On Qui, 2016-11-17 at 12:25 -0800, Adam Williamson wrote: > On Thu, 2016-11-17 at 12:18 -0800, Chris Murphy wrote: > > > > On Thu, Nov 17, 2016 at 10:26 AM, Adam Williamson > > wrote: > > > > > > > > You'll notice we don't explicitly specify *how* you should do > >

Re: Recommended upgrade procedure for >1 release upgrades

On 17/11/16 12:04 PM, Christian Dersch wrote: > > On 11/17/2016 09:01 PM, Luya Tshimbalanga wrote: >> On 17/11/16 10:26 AM, Adam Williamson wrote: >>> Hi, folks! >>> >>> While looking into an issue with how GNOME Software decides which >>> release to offer an upgrade to when there's more than one

Re: Recommended upgrade procedure for >1 release upgrades

On Thu, Nov 17, 2016 at 12:25 PM, Adam Williamson wrote: > On Thu, 2016-11-17 at 12:18 -0800, Chris Murphy wrote: >> On Thu, Nov 17, 2016 at 10:26 AM, Adam Williamson >> wrote: >> >> > You'll notice we don't explicitly specify *how* you

Re: Recommended upgrade procedure for >1 release upgrades

On Thu, 2016-11-17 at 12:18 -0800, Chris Murphy wrote: > On Thu, Nov 17, 2016 at 10:26 AM, Adam Williamson > wrote: > > > You'll notice we don't explicitly specify *how* you should do this. > > That is, > > if you're currently running Fedora 23, and you want to

Re: Recommended upgrade procedure for >1 release upgrades

On Thu, Nov 17, 2016 at 10:26 AM, Adam Williamson wrote: > You'll notice we don't explicitly specify *how* you should do this. That is, > if you're currently running Fedora 23, and you want to upgrade to Fedora 25 > next week, are you supposed to: > > i) Upgrade to

Re: Recommended upgrade procedure for >1 release upgrades

On Thu, Nov 17, 2016 at 3:01 PM, Luya Tshimbalanga wrote: > On 17/11/16 10:26 AM, Adam Williamson wrote: >> Hi, folks! >> >> While looking into an issue with how GNOME Software decides which >> release to offer an upgrade to when there's more than one plausible >>

Re: Recommended upgrade procedure for >1 release upgrades

On 11/17/2016 09:01 PM, Luya Tshimbalanga wrote: > On 17/11/16 10:26 AM, Adam Williamson wrote: >> Hi, folks! >> >> While looking into an issue with how GNOME Software decides which >> release to offer an upgrade to when there's more than one plausible >> candidate, I noticed something

Re: Recommended upgrade procedure for >1 release upgrades

On 17/11/16 10:26 AM, Adam Williamson wrote: > Hi, folks! > > While looking into an issue with how GNOME Software decides which > release to offer an upgrade to when there's more than one plausible > candidate, I noticed something interesting: we do not actually have a > policy on what we

Recommended upgrade procedure for >1 release upgrades

Hi, folks! While looking into an issue with how GNOME Software decides which release to offer an upgrade to when there's more than one plausible candidate, I noticed something interesting: we do not actually have a policy on what we 'recommend' people to do in this case. There's one