Re: Workaround for Re: Broken system upgrade due to rich dependencies

[Zbigniew Jędrzejewski-Szmek]

On Fri, Mar 09, 2018 at 11:05:55AM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I have built RPM with backported with/without/unless rich deps for F26.
> 
> https://copr.fedorainfracloud.org/coprs/ignatenkobrain/rpm-4.13.x-richd
> eps/
> 
> Just update from this repo before doing distro-sync/system-upgrade and
> you should be good.

Should this be advertised more widely through a Fedora Magazine article
or Common Bugs or something like that?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Workaround for Re: Broken system upgrade due to rich dependencies

[Nico Kadel-Garcia]

On Fri, Mar 9, 2018 at 5:05 AM, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I have built RPM with backported with/without/unless rich deps for F26.
>
> https://copr.fedorainfracloud.org/coprs/ignatenkobrain/rpm-4.13.x-richd
> eps/
>
> Just update from this repo before doing distro-sync/system-upgrade and
> you should be good.

That seems very sensible.

One of my favorite workarounds when yum, dnf, or even possibly RPM
changed too much between releases, and I still want to do the upgrade
manually, is to mirror the entire repository locally, without the
repodata/* files, and rebuild the repodata on the relevant local
mirror. Then use "that". for the update. There was an occasion years
ago when I had to use "rpm2cpio" to replace RPM components with the
newer version, and if *that* wound up messed up as well there's an
ancient script called "rpm2cpio.sh" described at
https://www.redhat.com/archives/rpm-list/2003-June/msg00367.html .It's
a useful tool for when RPM updates are completely botched, for
whatever reason. Such reasons include someone doing python module
updates that are inconflict with current releases. That script isn't
something I recommend doing lightly, but it can be invaluable when RPM
gets really mucked up, for any reason.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Stephen John Smoogen]

On 8 March 2018 at 14:37, Tony Nelson  wrote:
> On 18-03-07 14:14:38, Nicolas Mailhot wrote:
>>
>> Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
>> > On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
>> >  wrote:
>> > > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit
>> > > :
>> > > >
>> > > > I don't know if this is useful but in the RHL and early Fedora
>> > > > days,
>> > > > the way to do inplace upgrades was to first update just the 'core'
>> > > > tools needed by rpm.
>> >
>> > This is a totally unrelated comment, but I will personally send you $5
>> > if you can configure your email client to stop adding  in the
>> > Subject line for every thread you reply to.
>>
>> I'm pretty sure that's added by one of the MTAs in the chain between
>> Fedora SMTP and my ISP MTA, to attest they did DKIM verification, since
>> I see it already positioned on some received messages before I ever
>> replied to them.
>
>
> Presumably by bastion01.phx2.fedoraproject.org (Postfix), which adds the
> lines:
>

No, I don't think so. I can't find anything in the configuration which
would do this and I have a sneaking suspicion that if it was bastion
then most emails would get their subject changed. After going through
most of the email logs for the last 2 days, the only emails which
consistently passed DKIM tests were SPAM from various shady sources.
Most user email do not pass DKIM tests on any of the spamassassin logs
we have. So I would expect a lot of people to see DKIM in their
headers. The only one I could find is email from Nicholas.

The problem looks to be what Nicholas said in a different email about
mailman not stripping headers. The laposte servers are particular
about how they interpret simple DKIM signatures versus wraparound and
this is where his replies seem to fork a new thread. [There are
multiple types of DKIM headers depending on whether email servers only
limit to X characters per line or similar limitations].

In any case, the mailman3 server will now dkim from emails and will
see if that fixes the issue. If it doesn't then we will go to see what
else could be causing the issue.


> DKIM-Filter: OpenDKIM Filter v2.11.0 bastion01.phx2.fedoraproject.org
>  2E4116051DFD
> Authentication-Results: bastion01.phx2.fedoraproject.org;   dkim=fail
>  reason="signature verification failed" (2048-bit key) header.d=laposte.net
>  header.i=@laposte.net header.b="bKrmUuvt"
>
> --
> 
> TonyN.:'   
>   '  
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Workaround for Re: Broken system upgrade due to rich dependencies

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have built RPM with backported with/without/unless rich deps for F26.

https://copr.fedorainfracloud.org/coprs/ignatenkobrain/rpm-4.13.x-richd
eps/

Just update from this repo before doing distro-sync/system-upgrade and
you should be good.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqiXIMACgkQaVcUvRu8
X0ysVhAAgFIYwX2GUMxT2PGWjhEXuVyvuunLl5maKoHqDCsRGQcfm2SH1iiiWLKi
4Q9d1A3/GWZycxKez4P1sZ7Cqj8hvs9eUmJVzyxqH1ubRMk9Ws/RKDe2cwzUkm68
z9/5yIEIqHPqLc9mU+0xZ4mM6FbsLNS1Ps1V5TOn7OVpYnoxS56OeNbakjGBtuBB
Y00tkKyjancnJYwzAVzqSh5unRGpJ7+VxX5qNS630zN6YZMKDHA1lLJCUq50/f7C
T+CBDY19gKoUiNnPGHhDT/DJwDBhjw0nRUmQqu7wKLoLx2iwq5w9bMSZBTL4EnIJ
3RuVBwVMg0U5r9u18pO4vRp83tnK8ErIZQlPUAIng7ZeYObFnyhJQALRylTln65u
YbNh/Aee729SX+o75M22d4FN/tQYM2/Ef/sf/T2pFg2cNuV7miHS5iG721fbarFb
ZSgJf2cM717awF7TOq76XKwoepyQop5J95NO/AqGo3l0ta3Z6mM/MXYFbhujjuBY
biukhAprEoMG2zqU+lTw9kktZXsIdMosuLPyUVDMesdrc8AJZjoNUpdJFsWWhaMS
xbao+vqHqiZLCBedP9fbsrQcx2AiGAbnkucquONDlPHgXiXBkVUnO3LjleK4l3gf
+1lL+xq0oLZzNjprujHzkWglq0BASUiN3PdgdaC19Jaeky+iSGM=
=y67K
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Jason L Tibbitts III]

> "PM" == Panu Matilainen  writes:

PM> It's not a solution because doing so usually drags half the distro
PM> along due to library dependencies etc.

That's true if you're updating to the rpm/dnf/whatever from the distro
you want to upgrade to.  That's not true if you're updating to a new
version of rpm/dnf/whatever which supports the new features you need but
which has been built for the version of the distro you're currently
running.

But yes, I know how unpleasant it would be to have to somehow maintain
that magical package set in a separate "you're about to update your
distro" repository, and that it could still have issues when the minimum
supported versions of dependencies change.  Is it worse than some of the
other solutions?  I'm not sure.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 15:47 -0500, Stephen John Smoogen a écrit :
> On 8 March 2018 at 15:32, Stephen John Smoogen 
> wrote:
> > On 8 March 2018 at 13:38, Nicolas Mailhot  > et> wrote:
> > I have spent this afternoon going through many of your emails and
> > our
> > logs so I could find try to figure out what to help you. Coming back
> > and finding you blaming everyone else is insulting to my time and
> > tiresome. You are better than this.
> > 
> 
> You also deserved better from me in that I should have sent that email
> only to you versus the entire list. I apologize for my conduct as it
> was rude.

Everyone is tired and touchy and I'd rather have spend my time on
finishing up my packages. Nevertheless, since I spent my time on this, I
believe the listserver is invalidating dkim signatures by appending
footers to signed messages without removing those signatures, which
causes some MTAs like my ISP's to add  prefixes to subjects, and
others to flag messages from the listserver as spam.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Dennis Gilmore]

El jue, 08-03-2018 a las 12:55 +0200, Panu Matilainen escribió:
> On 03/08/2018 12:42 PM, Panu Matilainen wrote:
> > On 03/08/2018 12:21 PM, Reindl Harald wrote:
> > > 
> > > 
> > > Am 08.03.2018 um 08:53 schrieb Panu Matilainen:
> > > > P.P.S. So why didn't yum have anything like that? Because back
> > > > then, 
> > > > there were other upgrade methods that did run on the "target
> > > > stack": 
> > > > anaconda, preupgrade, fedup to name a few
> > > 
> > > and i never used one of them - i did hundrets of dist-upgrades
> > > for 
> > > more than a decade on dozens of machines (workstations and
> > > production 
> > > servers) with yum/dnf - full stop
> > 
> > Sure. You just either didn't upgrade between versions that
> > introduced a 
> > new rpmlib() dependency or updated rpm first, one way or the
> > other. 
> 
> ...or the couple of features were introduced in that period were
> done 
> using the one generic solution at hand I did mention in my earlier 
> email: wait until the previous Fedora supports the new feature too 
> before enabling in the new. Come to think of it, I think this was
> mostly 
> the case. It'd be in the ml archives if somebody wants to dig (we're 
> talking about rpm 4.6 - 4.7 era, SHA256 file digests and XZ payload 
> compression being the big ones I can remember offhand)
> 
> Oh, and of course back then it was nearly impossible to introduce
> such 
> features in the first place because the builders were running RHEL. 
> Those couple of features that were introduced required a custom rpm
> to 
> be used on builders. Those were the days... no I dont miss.
> 
I do not miss those days either, but we knew and communicated the
changes. and managed them so upgrades would work. We were careful to
make sure that the change was managed. Maybe too careful. Managing
hybrid systems for building was a pain and I never want to go do that
again.  We do need to make sure that as new rpm/dnf features are
supported that we have everything in place to fully support them,  that
means waiting for a short period of time from being in RPM to being
something we can tell packagers to go and use.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Stephen John Smoogen]

On 8 March 2018 at 15:32, Stephen John Smoogen  wrote:
> On 8 March 2018 at 13:38, Nicolas Mailhot  wrote:

> I have spent this afternoon going through many of your emails and our
> logs so I could find try to figure out what to help you. Coming back
> and finding you blaming everyone else is insulting to my time and
> tiresome. You are better than this.
>

You also deserved better from me in that I should have sent that email
only to you versus the entire list. I apologize for my conduct as it
was rude.


>> So it should either not do that or strip the signature when modifying
>> the message.
>>
>> Modern mail systems are so much fun
>>
>> --
>> Nicolas Mailhot
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Stephen John Smoogen]

On 8 March 2018 at 13:38, Nicolas Mailhot  wrote:
> Le jeudi 08 mars 2018 à 17:57 +, Tom Hughes a écrit :
>>
>> No, it almost certainly means that laposte.net have announced via
>> their DNS records that emails with laposte.net addresses should not
>> be trusted unless they come direct from a laposte.net server.
>
> Actually, it probably means the fedora listserver broke the DKIM
> signature by appending a list footer  to the message.
>

Laposte is saying your emails are wrong before it gets to the
listserver. As far as I can tell your email goes as follows:



 {sometimes}
 {sometimes}
 {sometimes}





Sometimes your emails get 1 laposte SMTP outbound, and sometimes all
3. Sometimes none of them are being used and the ddns.net one is
talking to fedora directly. Depending on which of the smtp servers you
are going through, one (or more) of them is altering that your DKIM
signature from the previous ones is not valid and changing the subject
line.

I have spent this afternoon going through many of your emails and our
logs so I could find try to figure out what to help you. Coming back
and finding you blaming everyone else is insulting to my time and
tiresome. You are better than this.

> So it should either not do that or strip the signature when modifying
> the message.
>
> Modern mail systems are so much fun
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Tony Nelson]

On 18-03-07 14:14:38, Nicolas Mailhot wrote:

Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
> On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
>  wrote:
> > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a  
écrit

> > :
> > >
> > > I don't know if this is useful but in the RHL and early Fedora
> > > days,
> > > the way to do inplace upgrades was to first update just the  
'core'

> > > tools needed by rpm.
>
> This is a totally unrelated comment, but I will personally send you  
$5

> if you can configure your email client to stop adding  in the
> Subject line for every thread you reply to.

I'm pretty sure that's added by one of the MTAs in the chain between
Fedora SMTP and my ISP MTA, to attest they did DKIM verification,  
since

I see it already positioned on some received messages before I ever
replied to them.


Presumably by bastion01.phx2.fedoraproject.org (Postfix), which adds the
lines:

DKIM-Filter: OpenDKIM Filter v2.11.0 bastion01.phx2.fedoraproject.org
 2E4116051DFD
Authentication-Results: bastion01.phx2.fedoraproject.org;	 
dkim=fail
 reason="signature verification failed" (2048-bit key)  
header.d=laposte.net

 header.i=@laposte.net header.b="bKrmUuvt"

--

TonyN.:'   
  '  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 17:57 +, Tom Hughes a écrit :
> 
> No, it almost certainly means that laposte.net have announced via
> their DNS records that emails with laposte.net addresses should not
> be trusted unless they come direct from a laposte.net server.

Actually, it probably means the fedora listserver broke the DKIM
signature by appending a list footer  to the message.

So it should either not do that or strip the signature when modifying
the message.

Modern mail systems are so much fun

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Tom Hughes]

On 08/03/18 17:46, Nicolas Mailhot wrote:

Le jeudi 08 mars 2018 à 18:11 +0100, Fabio Valentini a écrit :


Additionally, I frequently get Spam warnings for your e-mails because
they don't pass the validation tests for being sent from a laposte.net
address.


That tells a lot more about USA operators being not willing to work with
non USA operators than anything else.


No, it almost certainly means that laposte.net have announced via
their DNS records that emails with laposte.net addresses should not
be trusted unless they come direct from a laposte.net server.

Of course when you send email to a mailing list the list has to
resend it, meaning it no longer appears to come from a laposte.net
server and an recipient that acts on the announced policy will
wind up rejecting it.

The act of making that announcement is the problem because it is
based on a fundamental misunderstanding of how email is used.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

unproductive finger pointing; was: Re: Broken system upgrade due to rich dependencies

[R P Herrold]

On Thu, 8 Mar 2018, Nicolas Mailhot wrote:

> That tells a lot more about USA operators being not willing to work with
> non USA operators than anything else.

ehh?

from the headers in that post, as received by me:

X-Authentication-Results: bastion01.phx2.fedoraproject.org;
dkim=fail reason="signature verification failed" (2048-bit key)
header.d=laposte.net header.i=@laposte.net header.b="EPfsBz5c"

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 18:11 +0100, Fabio Valentini a écrit :
> 
> Additionally, I frequently get Spam warnings for your e-mails because
> they don't pass the validation tests for being sent from a laposte.net
> address.

That tells a lot more about USA operators being not willing to work with
non USA operators than anything else.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Yanko Kaneti]

On Thu, 2018-03-08 at 17:47 +0100, Nicolas Mailhot wrote:
> Le jeudi 08 mars 2018 à 18:15 +0200, Yanko Kaneti a écrit :
> > 
> > Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds
> > because nobody but you would see it.
> 
> And what, exactly, do you think answers to those mails look like once
> they had this added on the incoming route? You're not thinking it
> through.

Well, what the answers look like is entirely controlled by your email
client and your outgoing MTA.

I was indeed overthinking it. The simplest explanation of course is that
you personally don't care what crap ends in the subjects of your
replies, so you are just hitting reply and just spreading whatever your
incoming MTA tags on the Subject.

- Yanko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Fabio Valentini]

On Thu, Mar 8, 2018 at 5:47 PM, Nicolas Mailhot
 wrote:
> Le jeudi 08 mars 2018 à 18:15 +0200, Yanko Kaneti a écrit :
>>
>> Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds
>> because nobody but you would see it.
>
> And what, exactly, do you think answers to those mails look like once
> they had this added on the incoming route? You're not thinking it
> through.

For what it's worth, the only mails that start new threads (because of
the added "RE: " to the Subject line) are sent by you, Nicolas.
Additionally, I frequently get Spam warnings for your e-mails because
they don't pass the validation tests for being sent from a laposte.net
address.
So it really looks like there's something wrong with your setup.

Fabio

> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 18:15 +0200, Yanko Kaneti a écrit :
> 
> Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds
> because nobody but you would see it.

And what, exactly, do you think answers to those mails look like once
they had this added on the incoming route? You're not thinking it
through.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Yanko Kaneti]

On Wed, 2018-03-07 at 20:14 +0100, Nicolas Mailhot wrote:
> Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
> > On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
> >  wrote:
> > > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a
> > > écrit
> > > :
> > > > 
> > > > I don't know if this is useful but in the RHL and early Fedora
> > > > days,
> > > > the way to do inplace upgrades was to first update just the
> > > > 'core'
> > > > tools needed by rpm.
> > 
> > This is a totally unrelated comment, but I will personally send you
> > $5
> > if you can configure your email client to stop adding  in the
> > Subject line for every thread you reply to.
> 
> I'm pretty sure that's added by one of the MTAs in the chain between
> Fedora SMTP and my ISP MTA, to attest they did DKIM verification,
> since
> I see it already positioned on some received messages before I ever
> replied to them.

Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds it ,
because nobody but you would see it.

The problem is that (perhaps the same) MTA on the way 
your-email-client->fedora-ml does it. 


> And not all of them, only for senders that use a mail host that
> provides
> DKIM info.

Perhaps that middle box MTA that you are relaying through thinks the
same about your initial sending host and adds it to all your outgoing
mail.


-Yanko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 02:23 PM, Neal Gompa wrote:

On Thu, Mar 8, 2018 at 6:48 AM, Panu Matilainen  wrote:

On 03/08/2018 01:39 PM, Neal Gompa wrote:


On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen 
wrote:


On 03/07/2018 03:10 PM, Neal Gompa wrote:



On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:



And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).



This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.



Bottom line: either dnf (or something else) grows an dist-upgrade method
that runs the transaction on the "target stack" OR Fedora is *forced* to
hold back on new rpm package features until all the active versions have
a
rpm/dnf stack that can handle them. Period. No ifs or buts.

P.S. No, updating rpm + dnf first in a separate transaction is not a
solution at all.



You're right in that upgrading rpm + dnf + libsolv first won't fix it
100% of the time (mainly with features that can't be guarded by
rpmlib() dependencies, such as the new header size), but I think it'll
deal with more than 80% of the cases where we have a problem, such
that distribution upgrades through this mechanism will work as we
introduce new features in the distribution.

But I would disagree that updating rpm + dnf first is not a solution
at all. It's not a *perfect* solution, but it would help a hell of a
lot more.



It's not a solution because doing so usually drags half the distro along due
to library dependencies etc.



I suppose part of this is because the way we package libraries makes
it so that new library packages _must_ replace older ones as sonames
change. In Mageia and openSUSE, it doesn't work like that at all.
You'll get your new library dependencies for the RPM stack and then it
would re-execute with that target, and then upgrade the remainder of
the system.


Hell, even preupgrade and older mechanisms more or less
worked by getting the target rpm and package manager code installed
first and then doing the real thing using that code.



No, preupgrade & friends basically created a special boot target that runs
the whole thing with the new version, in an isolated environment. Which
equals "using the target rpm stack" in fact.



In my mind, that's functionally equivalent. Yes, it's not actually on
the target yet, but it operates under the newer rpm environment.


This sounds like there's supposedly a disagreement somewhere in there 
but I don't know what it is. Details about how exactly preupgrade and 
friends went about their business maybe, but ultimately they did exactly 
what is being discussed: run the upgrade transaction on the target 
stack, because they created/downloaded/whatever a minimal environemnt 
from which to chroot-upgrade the actual root. That is *the* generic 
solution to this whole thing. Clearly there was something wrong with 
preupgrade & all or they wouldn't have been abandoned, but they did that 
one thing right.




And supporting transaction ordering such that transactions can be
broken up into smaller ones as needed based on various conditions
would make upgrades more reliable in general, in my opinion.



That's quite a different thing, and creates it's own quirks and issues. And
it doesn't help things at all when the simple "dnf update rpm dnf" drags
along for example a new glibc or python version which snowballs into 70% of
the distro getting pulled into the "just update rpm" transaction.



New glibc versions by itself should not snowball into 70% of
distribution, otherwise something is broken with how the dependencies
are versioned.

As for pulling in a new Python, you're right that it's an issue, but
it's an issue no matter what. Even when it's in the same transaction,
it's all broken until everything is upgraded anyway. And if we're
talking about this being done with system-upgrade or dist-upgrade
commands, then we can reasonably expect that we can upgrade a subset
first, then restart DNF with the new stack, and pass in the remainder
of the transaction to complete.

That said, stuff like this with the Python stuff makes me think we
should have pythonX.Y-foo packages that have Obsoletes/Provides
pythonX-foo instead, so that stuff wouldn't actually break like this.
But that's another discussion...

And also, PackageKit offline upgrades wouldn't be affected by the
Python bit and could happily do this "properly", if the Python bit is
what you're worried about.


Python is just one example, PackageKit (like almost everything) has 
their non-trivial dependencies that also snowball.


>

Another way to solve that problem would be to have a minimal C/C++
implementation that DNF would hand off to for system upgrades to avoid
the Python issue. Personally, I don't think that's necessary, all
things considered, but it's an option.

But I think we *really* should have the splitting 

Re: Broken system upgrade due to rich dependencies

[Neal Gompa]

On Thu, Mar 8, 2018 at 6:48 AM, Panu Matilainen  wrote:
> On 03/08/2018 01:39 PM, Neal Gompa wrote:
>>
>> On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen 
>> wrote:
>>>
>>> On 03/07/2018 03:10 PM, Neal Gompa wrote:


 On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
  wrote:
>
>
> And you forgot:
> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> proper way).
>

 This has been requested for a long time:
 https://bugzilla.redhat.com/show_bug.cgi?id=1032541

 It'd be *really* good if DNF implemented it.
>>>
>>>
>>> Bottom line: either dnf (or something else) grows an dist-upgrade method
>>> that runs the transaction on the "target stack" OR Fedora is *forced* to
>>> hold back on new rpm package features until all the active versions have
>>> a
>>> rpm/dnf stack that can handle them. Period. No ifs or buts.
>>>
>>> P.S. No, updating rpm + dnf first in a separate transaction is not a
>>> solution at all.
>>>
>>
>> You're right in that upgrading rpm + dnf + libsolv first won't fix it
>> 100% of the time (mainly with features that can't be guarded by
>> rpmlib() dependencies, such as the new header size), but I think it'll
>> deal with more than 80% of the cases where we have a problem, such
>> that distribution upgrades through this mechanism will work as we
>> introduce new features in the distribution.
>>
>> But I would disagree that updating rpm + dnf first is not a solution
>> at all. It's not a *perfect* solution, but it would help a hell of a
>> lot more.
>
>
> It's not a solution because doing so usually drags half the distro along due
> to library dependencies etc.
>

I suppose part of this is because the way we package libraries makes
it so that new library packages _must_ replace older ones as sonames
change. In Mageia and openSUSE, it doesn't work like that at all.
You'll get your new library dependencies for the RPM stack and then it
would re-execute with that target, and then upgrade the remainder of
the system.

>> Hell, even preupgrade and older mechanisms more or less
>> worked by getting the target rpm and package manager code installed
>> first and then doing the real thing using that code.
>
>
> No, preupgrade & friends basically created a special boot target that runs
> the whole thing with the new version, in an isolated environment. Which
> equals "using the target rpm stack" in fact.
>

In my mind, that's functionally equivalent. Yes, it's not actually on
the target yet, but it operates under the newer rpm environment.

>>
>> And supporting transaction ordering such that transactions can be
>> broken up into smaller ones as needed based on various conditions
>> would make upgrades more reliable in general, in my opinion.
>>
>
> That's quite a different thing, and creates it's own quirks and issues. And
> it doesn't help things at all when the simple "dnf update rpm dnf" drags
> along for example a new glibc or python version which snowballs into 70% of
> the distro getting pulled into the "just update rpm" transaction.
>

New glibc versions by itself should not snowball into 70% of
distribution, otherwise something is broken with how the dependencies
are versioned.

As for pulling in a new Python, you're right that it's an issue, but
it's an issue no matter what. Even when it's in the same transaction,
it's all broken until everything is upgraded anyway. And if we're
talking about this being done with system-upgrade or dist-upgrade
commands, then we can reasonably expect that we can upgrade a subset
first, then restart DNF with the new stack, and pass in the remainder
of the transaction to complete.

That said, stuff like this with the Python stuff makes me think we
should have pythonX.Y-foo packages that have Obsoletes/Provides
pythonX-foo instead, so that stuff wouldn't actually break like this.
But that's another discussion...

And also, PackageKit offline upgrades wouldn't be affected by the
Python bit and could happily do this "properly", if the Python bit is
what you're worried about.

Another way to solve that problem would be to have a minimal C/C++
implementation that DNF would hand off to for system upgrades to avoid
the Python issue. Personally, I don't think that's necessary, all
things considered, but it's an option.

But I think we *really* should have the splitting transactions
feature, not just for system upgrades, but for dealing with a litany
of conditions that may make it difficult to do "big" transactions.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 01:39 PM, Neal Gompa wrote:

On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen  wrote:

On 03/07/2018 03:10 PM, Neal Gompa wrote:


On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:


And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).



This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.


Bottom line: either dnf (or something else) grows an dist-upgrade method
that runs the transaction on the "target stack" OR Fedora is *forced* to
hold back on new rpm package features until all the active versions have a
rpm/dnf stack that can handle them. Period. No ifs or buts.

P.S. No, updating rpm + dnf first in a separate transaction is not a
solution at all.



You're right in that upgrading rpm + dnf + libsolv first won't fix it
100% of the time (mainly with features that can't be guarded by
rpmlib() dependencies, such as the new header size), but I think it'll
deal with more than 80% of the cases where we have a problem, such
that distribution upgrades through this mechanism will work as we
introduce new features in the distribution.

But I would disagree that updating rpm + dnf first is not a solution
at all. It's not a *perfect* solution, but it would help a hell of a
lot more. 


It's not a solution because doing so usually drags half the distro along 
due to library dependencies etc.



Hell, even preupgrade and older mechanisms more or less
worked by getting the target rpm and package manager code installed
first and then doing the real thing using that code.


No, preupgrade & friends basically created a special boot target that 
runs the whole thing with the new version, in an isolated environment. 
Which equals "using the target rpm stack" in fact.




And supporting transaction ordering such that transactions can be
broken up into smaller ones as needed based on various conditions
would make upgrades more reliable in general, in my opinion.



That's quite a different thing, and creates it's own quirks and issues. 
And it doesn't help things at all when the simple "dnf update rpm dnf" 
drags along for example a new glibc or python version which snowballs 
into 70% of the distro getting pulled into the "just update rpm" 
transaction.


- Panu -





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Neal Gompa]

On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen  wrote:
> On 03/07/2018 03:10 PM, Neal Gompa wrote:
>>
>> On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
>>  wrote:
>>>
>>> And you forgot:
>>> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
>>> proper way).
>>>
>>
>> This has been requested for a long time:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1032541
>>
>> It'd be *really* good if DNF implemented it.
>
> Bottom line: either dnf (or something else) grows an dist-upgrade method
> that runs the transaction on the "target stack" OR Fedora is *forced* to
> hold back on new rpm package features until all the active versions have a
> rpm/dnf stack that can handle them. Period. No ifs or buts.
>
> P.S. No, updating rpm + dnf first in a separate transaction is not a
> solution at all.
>

You're right in that upgrading rpm + dnf + libsolv first won't fix it
100% of the time (mainly with features that can't be guarded by
rpmlib() dependencies, such as the new header size), but I think it'll
deal with more than 80% of the cases where we have a problem, such
that distribution upgrades through this mechanism will work as we
introduce new features in the distribution.

But I would disagree that updating rpm + dnf first is not a solution
at all. It's not a *perfect* solution, but it would help a hell of a
lot more. Hell, even preupgrade and older mechanisms more or less
worked by getting the target rpm and package manager code installed
first and then doing the real thing using that code.

And supporting transaction ordering such that transactions can be
broken up into smaller ones as needed based on various conditions
would make upgrades more reliable in general, in my opinion.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 12:42 PM, Panu Matilainen wrote:

On 03/08/2018 12:21 PM, Reindl Harald wrote:



Am 08.03.2018 um 08:53 schrieb Panu Matilainen:
P.P.S. So why didn't yum have anything like that? Because back then, 
there were other upgrade methods that did run on the "target stack": 
anaconda, preupgrade, fedup to name a few


and i never used one of them - i did hundrets of dist-upgrades for 
more than a decade on dozens of machines (workstations and production 
servers) with yum/dnf - full stop


Sure. You just either didn't upgrade between versions that introduced a 
new rpmlib() dependency or updated rpm first, one way or the other. 


...or the couple of features were introduced in that period were done 
using the one generic solution at hand I did mention in my earlier 
email: wait until the previous Fedora supports the new feature too 
before enabling in the new. Come to think of it, I think this was mostly 
the case. It'd be in the ml archives if somebody wants to dig (we're 
talking about rpm 4.6 - 4.7 era, SHA256 file digests and XZ payload 
compression being the big ones I can remember offhand)


Oh, and of course back then it was nearly impossible to introduce such 
features in the first place because the builders were running RHEL. 
Those couple of features that were introduced required a custom rpm to 
be used on builders. Those were the days... no I dont miss.


 - Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 12:21 PM, Reindl Harald wrote:



Am 08.03.2018 um 08:53 schrieb Panu Matilainen:
P.P.S. So why didn't yum have anything like that? Because back then, 
there were other upgrade methods that did run on the "target stack": 
anaconda, preupgrade, fedup to name a few


and i never used one of them - i did hundrets of dist-upgrades for more 
than a decade on dozens of machines (workstations and production 
servers) with yum/dnf - full stop


Sure. You just either didn't upgrade between versions that introduced a 
new rpmlib() dependency or updated rpm first, one way or the other. 
Neither of which are generic solutions to the problem.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 09:53 AM, Panu Matilainen wrote:

On 03/07/2018 03:10 PM, Neal Gompa wrote:

On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:

And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).



This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.


That's quite an understatement.

It's rpm's responsibility to keep track of its features. If things had 
been the way they're supposed to be, rpm would've simply *prevented dnf* 
from doing this upgrade-gone-bad. And now let the implications of that 
sink in for a moment.


Rich dependencies are tracked with an rpmlib() dependency, however that 
didn't get adjusted for the new dependencies introduced in 4.14, they 
just slipped through reviews without any of us noticing. So it's a bug 
in rpm, and kinda hard to fix after the fact because all those packages 
that would need the tracking dependency are already out there.


A handful of mishandled dependencies is one thing. A change like switch 
to different payload compressor is something quite different, you just 
could not upgrade no matter how much you wanted to. And now, let the 
implications of THAT sink in for a moment.


New rpmlib() dependencies occur every now and then, but since it's not a 
monthly event people keep forgetting. Happens predictably every time. 
And judging by me hardly recognizing any names on the DNF team, there's 
so much new blood on board that they might not even know this in the 
first place.


Bottom line: either dnf (or something else) grows an dist-upgrade method 
that runs the transaction on the "target stack" OR Fedora is *forced* to 
hold back on new rpm package features until all the active versions have 
a rpm/dnf stack that can handle them. Period. No ifs or buts.


P.S. No, updating rpm + dnf first in a separate transaction is not a 
solution at all.


P.P.S. So why didn't yum have anything like that? Because back then, 
there were other upgrade methods that did run on the "target stack": 
anaconda, preupgrade, fedup to name a few.


P.P.P.S. If you haven't read Asimov's Nightfall, you should. The 
difference is just that in our version, the cycle is short enough for 
there to be a few greybeards around that actually remember, but nobody 
listens those old demented fools ;)


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/07/2018 03:10 PM, Neal Gompa wrote:

On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:

And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).



This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.


That's quite an understatement.

It's rpm's responsibility to keep track of its features. If things had 
been the way they're supposed to be, rpm would've simply *prevented dnf* 
from doing this upgrade-gone-bad. And now let the implications of that 
sink in for a moment.


Rich dependencies are tracked with an rpmlib() dependency, however that 
didn't get adjusted for the new dependencies introduced in 4.14, they 
just slipped through reviews without any of us noticing. So it's a bug 
in rpm, and kinda hard to fix after the fact because all those packages 
that would need the tracking dependency are already out there.


A handful of mishandled dependencies is one thing. A change like switch 
to different payload compressor is something quite different, you just 
could not upgrade no matter how much you wanted to. And now, let the 
implications of THAT sink in for a moment.


New rpmlib() dependencies occur every now and then, but since it's not a 
monthly event people keep forgetting. Happens predictably every time. 
And judging by me hardly recognizing any names on the DNF team, there's 
so much new blood on board that they might not even know this in the 
first place.


Bottom line: either dnf (or something else) grows an dist-upgrade method 
that runs the transaction on the "target stack" OR Fedora is *forced* to 
hold back on new rpm package features until all the active versions have 
a rpm/dnf stack that can handle them. Period. No ifs or buts.


P.S. No, updating rpm + dnf first in a separate transaction is not a 
solution at all.


P.P.S. So why didn't yum have anything like that? Because back then, 
there were other upgrade methods that did run on the "target stack": 
anaconda, preupgrade, fedup to name a few.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
> On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
>  wrote:
> > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit
> > :
> > > 
> > > I don't know if this is useful but in the RHL and early Fedora
> > > days,
> > > the way to do inplace upgrades was to first update just the 'core'
> > > tools needed by rpm.
> 
> This is a totally unrelated comment, but I will personally send you $5
> if you can configure your email client to stop adding  in the
> Subject line for every thread you reply to.

I'm pretty sure that's added by one of the MTAs in the chain between
Fedora SMTP and my ISP MTA, to attest they did DKIM verification, since
I see it already positioned on some received messages before I ever
replied to them.

And not all of them, only for senders that use a mail host that provides
DKIM info.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le 2018-03-07 18:15, Reindl Harald a écrit :


if there wouldn't be dependencies in the real world making it risky
and difficult just update rpm itself

would you pull all dependencies down to glibc with that transaction?


If needed, yes, it is unsafe to install from a repo that has a newer rpm 
stack than the system one.



what if dnf itself don't work with that new rpm stack without rebuild?


That means building dnf from a new rpm is a special case that needs a 
buildroot override, not that everything else is a special case because 
the normal dnf use it pulling in rpm to rebuild itself.



how do you test that?


I certainly hope the rpm and dnf guys talk to each other and do not 
update the stack without taking the other needs in account.



how do you ensure that your tests are still true two months later?


That's the whole point, you don't need to, because you don't allow dnf 
installing packages from a repo with a newer rpm stack for months 
without updating rpm. The breakage, if any occurs directly at rpm update 
not months later once QA thinks everything is golden.


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Adam Williamson]

On Wed, 2018-03-07 at 09:13 -0500, Colin Walters wrote:
> 
> On Wed, Mar 7, 2018, at 5:52 AM, Igor Gnatenko wrote:
> > 
> > And you forgot:
> > 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> > proper way).
> 
> If you're using yum/dnf inside a container, the natural way to major upgrades 
> is
> to just pull the new base image and rebuild, rather than doing 
> update-in-place.
> Which has the semantics you're talking about.
> 
> For rpm-ostree, if you have no layered packages, depsolving etc. is not 
> involved
> at all, so it's completely immune to this problem.  If you have layered 
> packages,
> we do still use the libdnf from the booted deployment, but in the end if 
> something
> doesn't work you can temporarily drop your layered packages.  Down the line 
> we might
> try to do some libdnf parts inside a container in the new root, but that's a 
> huge change.

There are still a few of us living in the stone age, Colin, who aren't
using Fedora in a container *or* using ostree. Shocking, I know, but
it's true. :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[R P Herrold]

On Wed, 7 Mar 2018, Nicolas Mailhot wrote:

> It is quite insane, that, to this day, users are expected to know the
> rpm stack better than dnf, and tell it to update it first.
> 
> KNOWING THE PACKAGE INFRA STACK STACK IS THE INSTALLER JOB
> 
> whenever dnf hits a repo with an updated rpm stack, it should update the
> system rpm stack to this updated stack by default in a separate
> transaction, before installing anything from this repo.

As I recall from RHL days, and trying to do 'hot upgrades' 
across Major releases [it _could_ be done, but was not time 
effective], this also pulled in glibc (and kernel pairs in 
support of that glibc).  When such failed, it was time to go 
to the L0 backup ... and in Fedora and with new deployment 
automation and configuration orchestration, I suspect few 
people actually do a reboot, and a L0 backup, before every 
upgrade.

I would expect it to be useful to do the 'subset' upgrade
mentioned by Smooge for rpm and friends, _most_ of the time,
but occasionally (thinking here of an underlying DB version
bump and rebuild by RPM) not always

Perhaps scanning the transactionset, add a check and consult 
an optional:
- enable doing updates piecemail

flag.  If adding such a flag, I'd also add flags for 
potentially 'dangerous' transactions:
- warn me to take a L0,
- reboot first, and 
- reboot after a new kernel, glibc, or rpm

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Josh Boyer]

On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
 wrote:
> Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit :
>>
>> I don't know if this is useful but in the RHL and early Fedora days,
>> the way to do inplace upgrades was to first update just the 'core'
>> tools needed by rpm.

This is a totally unrelated comment, but I will personally send you $5
if you can configure your email client to stop adding  in the
Subject line for every thread you reply to.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit :
> 
> I don't know if this is useful but in the RHL and early Fedora days,
> the way to do inplace upgrades was to first update just the 'core'
> tools needed by rpm.

It is quite insane, that, to this day, users are expected to know the
rpm stack better than dnf, and tell it to update it first.

KNOWING THE PACKAGE INFRA STACK STACK IS THE INSTALLER JOB

whenever dnf hits a repo with an updated rpm stack, it should update the
system rpm stack to this updated stack by default in a separate
transaction, before installing anything from this repo.

That’s all it takes to stop wasting our time and Fedora user’s time on
this.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Stephen John Smoogen]

On 7 March 2018 at 05:40, Jaroslav Mracek  wrote:
> Recently, several users report problems with system upgrade due to rich 
> dependencies that are not supported by RPM in Fedora 25, and not fully 
> supported by RPM in Fedora 26 (statement 'with'). Rich dependencies are 
> allowed and supported from Fedora 26, but during the System Upgrade from 
> Fedora 25 the transaction is checked by RPM that doesn't support rich 
> dependencies, therefore the transaction check performed by RPM fails. A 
> similar situation can be experienced for System Upgrade from Fedora 26 where 
> RPM is unable to handle rich dependency using "with" statement 
> (https://bugzilla.redhat.com/show_bug.cgi?id=1551543). In future we can 
> expect that more and more users will be affected by the problem due to 
> increase of rich dependencies in Fedora 26-28. I realize that there were 
> similar issue discussed in 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/#7JWQ2TFDFYNCQFJBMOAQFIPDP4XCYLVC,
>  but it does not cover user point o
>  f view.
>
> Possible solution:
> 1. Back-port support of "with" key word in rich dependencies into Fedora 26 
> (solves only upgrades from 26 to 27, and 26 to 28.)
> 2. Ban rich dependencies in Fedora 26, and 27, and in 28 only rich deps using 
> "with" statement (solves all issues)
> 3. Provide a copr repo with RPM for Fedora 25, and 26 that support all rich 
> dependencies (user unfriendly)
> 4. Disable rich dependency check in RPM release for Fedora 26 (solves only 
> upgrades from 26 to 27, and 26 to 28.)
>

I don't know if this is useful but in the RHL and early Fedora days,
the way to do inplace upgrades was to first update just the 'core'
tools needed by rpm. Then you would normally need to do an rpmrebuild
to make everything correct. Then the install would be restarted and
completed with the new in place tools. However every now and then a
'flag' day would happen which meant that past updates could not be
done with an inplace update and an external one was needed. This
sounds like this is the case with rich dependencies which would have
been a reason to move rpm4 to rpm5 but ahem that wasn't possible.

Is there a way to get either a minimal update installer or a scripted
set of commands to allow for the above?


> The issue can be experienced in following system upgrade combinations: 25 to 
> 26, 25 to 27,  26 to 27, 26 to 28.
> The list of Fedora 27 and 28 packages with incompatible rich deps - 
> https://bugzilla.redhat.com/show_bug.cgi?id=1552547
>
> Best regards
>
>Jaroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Colin Walters]

On Wed, Mar 7, 2018, at 5:52 AM, Igor Gnatenko wrote:
>
> And you forgot:
> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> proper way).

If you're using yum/dnf inside a container, the natural way to major upgrades is
to just pull the new base image and rebuild, rather than doing update-in-place.
Which has the semantics you're talking about.

For rpm-ostree, if you have no layered packages, depsolving etc. is not involved
at all, so it's completely immune to this problem.  If you have layered 
packages,
we do still use the libdnf from the booted deployment, but in the end if 
something
doesn't work you can temporarily drop your layered packages.  Down the line we 
might
try to do some libdnf parts inside a container in the new root, but that's a 
huge change.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Neal Gompa]

On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:
> And you forgot:
> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> proper way).
>

This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-03-07 at 10:40 +, Jaroslav Mracek wrote:
> Recently, several users report problems with system upgrade due to
> rich dependencies that are not supported by RPM in Fedora 25, and not
> fully supported by RPM in Fedora 26 (statement 'with'). Rich
> dependencies are allowed and supported from Fedora 26, but during the
> System Upgrade from Fedora 25 the transaction is checked by RPM that
> doesn't support rich dependencies, therefore the transaction check
> performed by RPM fails. A similar situation can be experienced for
> System Upgrade from Fedora 26 where RPM is unable to handle rich
> dependency using "with" statement (https://bugzilla.redhat.com/show_b
> ug.cgi?id=1551543). In future we can expect that more and more users
> will be affected by the problem due to increase of rich dependencies
> in Fedora 26-28. I realize that there were similar issue discussed in
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/#7JWQ2TFDFYNCQFJBMOAQF
> IPDP4XCYLVC, but it does not cover user point o
>  f view.
> 
> Possible solution:
> 1. Back-port support of "with" key word in rich dependencies into
> Fedora 26 (solves only upgrades from 26 to 27, and 26 to 28.)

This is no-go, there are more incompatible changes in RPM.

> 2. Ban rich dependencies in Fedora 26, and 27, and in 28 only rich
> deps using "with" statement (solves all issues)

Thanks, no.

> 3. Provide a copr repo with RPM for Fedora 25, and 26 that support
> all rich dependencies (user unfriendly)

Agree, this is not "official" way of doing system upgrades.

> 4. Disable rich dependency check in RPM release for Fedora 26 (solves
> only upgrades from 26 to 27, and 26 to 28.)

I have proposed this to DNF team already, but nothing happened.

And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).

> The issue can be experienced in following system upgrade
> combinations: 25 to 26, 25 to 27,  26 to 27, 26 to 28.
> The list of Fedora 27 and 28 packages with incompatible rich deps - h
> ttps://bugzilla.redhat.com/show_bug.cgi?id=1552547

Once more, this issue is not only about rich dependencies:
> The maximum supported header size was significantly raised in this
release. This cannot be tracked with rpmlib() dependencies as that
requires accessing the header, so attempting to access packages with
larger than 32MB header will just abruptly fail with ALL older rpm
versions.

So if you use RPM 4.13 to install RPM 4.14-built package which happen
to have such large header, RPM would simply crash. Solutions 1-4 are
not sustainable, #5 is.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqfxGoACgkQaVcUvRu8
X0zxaRAAkIrFRnMxIZNPNlJqNWRcNwuqbWODwgRfwEUUv2JDEb6tY5z5L/2faZI2
xOpMfQJhx+7qx49yudAS9TbIQsHla1ffQA8YWgH+jxmLARGVlciklcpuoY4DobAQ
hbxbhewIyoK1xM72P/+XYUBu1yAhjsDEem3nZ/Fi/YJgIoJ0kABPgwf168LFQSjG
nUIZ50989p8uT0q/gtdIAGQrhLfxjWZQIBIZF+ctrq2TQr3Ag9zJaocysJBXtyCo
z0zFFN1mZuXHl+zpynGRK9/FmhlTVC/+83om3eM7HmqCv/xDcLdj+HU0NDYJJPJz
nB4/HVs6HLhvkB3FPODjxEc7jmQ51JT4Pz+cZMXggOiXW9qVEEm0H8afbxjZcDje
jZxuDfvNoD92uFG9iZOSPFLv3DfstcYNsGABu9lK+Ust/+++o6+a1XYgdvrd+8L+
dt9qANVyguZQYO0afFZ/gEjOwGoFQUk0AuGyMe30iVDUi203b5lQCebeN0rz8hE6
KtxKKEO23rD3hFG7WyVYUc8+ot2KYkG/WsS7JzlDTt5I8hlq7uJ2eWCnTpua/7ew
Lz+lc8ZgHe9mkwboMZtGGbsRWesQBU6tzYcwu1XP7apvM4iA+gniGngf6QgeJrcr
tEj90kl98tnE36CE1xszihBOtniqEKCq5kpR8a6MBekKZQX7HlM=
=Xl8n
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken system upgrade due to rich dependencies

[Jaroslav Mracek]

Recently, several users report problems with system upgrade due to rich 
dependencies that are not supported by RPM in Fedora 25, and not fully 
supported by RPM in Fedora 26 (statement 'with'). Rich dependencies are allowed 
and supported from Fedora 26, but during the System Upgrade from Fedora 25 the 
transaction is checked by RPM that doesn't support rich dependencies, therefore 
the transaction check performed by RPM fails. A similar situation can be 
experienced for System Upgrade from Fedora 26 where RPM is unable to handle 
rich dependency using "with" statement 
(https://bugzilla.redhat.com/show_bug.cgi?id=1551543). In future we can expect 
that more and more users will be affected by the problem due to increase of 
rich dependencies in Fedora 26-28. I realize that there were similar issue 
discussed in 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/#7JWQ2TFDFYNCQFJBMOAQFIPDP4XCYLVC,
 but it does not cover user point o
 f view.

Possible solution:
1. Back-port support of "with" key word in rich dependencies into Fedora 26 
(solves only upgrades from 26 to 27, and 26 to 28.)
2. Ban rich dependencies in Fedora 26, and 27, and in 28 only rich deps using 
"with" statement (solves all issues)
3. Provide a copr repo with RPM for Fedora 25, and 26 that support all rich 
dependencies (user unfriendly)
4. Disable rich dependency check in RPM release for Fedora 26 (solves only 
upgrades from 26 to 27, and 26 to 28.)

The issue can be experienced in following system upgrade combinations: 25 to 
26, 25 to 27,  26 to 27, 26 to 28.
The list of Fedora 27 and 28 packages with incompatible rich deps - 
https://bugzilla.redhat.com/show_bug.cgi?id=1552547

Best regards

   Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org