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 does
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 v
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 assigned to
>> > tibb
> 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
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
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 is
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 u
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.
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 whe
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
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 'recom
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
Fedora
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
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
>>>
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 a
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
specifica
> "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 package should be
AW> retired.
R
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] where
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 tran
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 disagre
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 w
> "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 contains a bunch of obsoletes fo
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 know
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
xorg
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 -- devel@lists
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 offer
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 stable?
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 it
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
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:
>
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
__
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
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 upg
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
> > > this.
> > > That is,
> > >
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 p
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 should do this.
>> > That is,
>> > if you're currently runni
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 upgrade to
> > Fedora 25
> > next w
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 Fedora 24 first, then from Fedo
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
>> candidate, I noticed something in
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 interestin
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 'recommen
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 specific
42 matches
Mail list logo
