On Tue, Jul 31, 2018 at 09:06:13AM +0200, Michael Mraka wrote:
> >
> > Is there a reason why we can't change YUM to match the DNF behavior?
> > IMO, the YUM behavior is nonsense and isn't even a valid package
> > identifier.
>
> Actually E:N-V-R.A is yum-ism no one else understand
> while
On Tue, Jul 31, 2018 at 3:40 PM Michal Novotny wrote:
> On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson wrote:
>
>> This simply is not true.
>>
>> Whatever "rpm format" means, historically RPM itself has always gone to
>> some lengths not to expose E: to users to simplify the endless fog of
>>
On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson wrote:
> This simply is not true.
>
> Whatever "rpm format" means, historically RPM itself has always gone to
> some lengths not to expose E: to users to simplify the endless fog of
> dependency hell clutter.
>
Yeah, something which is eluding my
Jeff Johnson:
> This simply is not true.
What is not true? Could you please include sentence you are referring to?
> Whatever "rpm format" means, historically RPM itself has always gone to some
> lengths not to expose E: to users to simplify the endless fog of dependency
> hell clutter.
Rpm
This simply is not true.
Whatever "rpm format" means, historically RPM itself has always gone to some
lengths not to expose E: to users to simplify the endless fog of dependency
hell clutter.
___
devel mailing list -- devel@lists.fedoraproject.org
To
Neal Gompa:
> > Regarding these two questions:
> >
> >>> Are there any concerns about such change?
> >>> I believe that >90% users wouldn't notice anything as it's related to the
> >>> history database only.
> >
> >> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko
> >> wrote:
> >> Since we've
This thread was about compatibility between dnf and yum: rpm itself has no
usage case identifying whether an rpmdb has been changed.
But you are correct that installation of a package by any tool -- including dnf
and rpm atm -- needlessly causes yum to warn that the rpmdb has changed which
is
I would like to see dnf history not being messed up by direct installations
with `rpm -i`.
While `dnf history` is a great feature, it would be even greater if the
related functionality
was implemented directly in rpmdb and both rpm and dnf used that db.
Meaning that
any consistency checks would
The real problem is that both E:N-V-R.A and N-E:V-R.A are equally imprecise.
The concept of "reproducible builds/installs" requires much more complete
identifiers for serious work. But that was not the question asked in this
thread.
So calculating both checksums, on rearranged plaintext
On 07/18/2018 09:24 AM, Daniel Mach wrote:
> Hi everyone,
> The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
> like to get feedback on this one:
> https://bugzilla.redhat.com/show_bug.cgi?id=1120253
>
> rpmdb checksum is a checksum of all installed RPMs
> It has no
Use headerFormat() with a configurable format string to extract the package
identifier item in the list that is check summed and have it both ways.
Why anyone wishes to preserve compatibility with yum's bloated history database
in order to flip between two depsolvers is left to RH TAM's to
On Thu, Jul 19, 2018 at 12:06 AM, Neal Gompa wrote:
> On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé
> wrote:
> >
> > On Wed, Jul 18, 2018 at 03:24:54PM +0200, Daniel Mach wrote:
> > > Hi everyone,
> > > The DNF team is currently reviewing DNF compatibility with YUM 3 and
> we'd
> > > like
On Wed, Jul 18, 2018 at 5:13 PM, Ben Cotton wrote:
> On Wed, Jul 18, 2018 at 11:02 AM Daniel Mach wrote:
>
> > If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
> > there will be continuity in used algorithm and history db checksums.
> > It's important to some enterprise
On Thu, Jul 19, 2018 at 3:26 PM, Neal Gompa wrote:
> On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling wrote:
>>
>> Regarding these two questions:
>>
Are there any concerns about such change?
I believe that >90% users wouldn't notice anything as it's related to the
history database
On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling wrote:
>
> Regarding these two questions:
>
>>> Are there any concerns about such change?
>>> I believe that >90% users wouldn't notice anything as it's related to the
>>> history database only.
>
>
>>
>> On Wed, Jul 18, 2018 at 10:01 AM Igor
On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé wrote:
>
> On Wed, Jul 18, 2018 at 03:24:54PM +0200, Daniel Mach wrote:
> > Hi everyone,
> > The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
> > like to get feedback on this one:
> >
> If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
> there will be continuity in used algorithm and history db checksums.
> It's important to some enterprise customers to keep the history db in a
> good shape.
> Fedora users don't care about that much in general.
I care
On Wed, Jul 18, 2018 at 11:02 AM Daniel Mach wrote:
> If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
> there will be continuity in used algorithm and history db checksums.
> It's important to some enterprise customers to keep the history db in a good
> shape.
> Fedora
On Wed, Jul 18, 2018 at 05:01:14PM +0200, Daniel Mach wrote:
> >
> > What's the benefit in changing to be compatible with YUM as opposed
> > to stickin with current alogorithm ?
> >
> If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
> there will be continuity in used
>
> What's the benefit in changing to be compatible with YUM as opposed
> to stickin with current alogorithm ?
>
If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
there will be continuity in used algorithm and history db checksums.
It's important to some enterprise customers
Regarding these two questions:
Are there any concerns about such change?
>> I believe that >90% users wouldn't notice anything as it's related to the
>> history database only.
>
>
> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko <
> ignatenkobr...@fedoraproject.org> wrote:
> Since we've changed
On Wed, Jul 18, 2018 at 3:35 PM Daniel Mach wrote:
> Hi everyone,
> The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
> like to get feedback on this one:
> https://bugzilla.redhat.com/show_bug.cgi?id=1120253
>
> rpmdb checksum is a checksum of all installed RPMs
> It has
On Wed, Jul 18, 2018 at 03:24:54PM +0200, Daniel Mach wrote:
> Hi everyone,
> The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
> like to get feedback on this one:
> https://bugzilla.redhat.com/show_bug.cgi?id=1120253
>
> rpmdb checksum is a checksum of all installed RPMs
Hi everyone,
The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
like to get feedback on this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1120253
rpmdb checksum is a checksum of all installed RPMs
It has no cryptographical value, it's just an unique ID of RPMs on a
24 matches
Mail list logo
