An entire *.rpm file needs to be read only because rpm-metadata chose the file
digest to be included in metadata.
There is no way for a plaintext file to contain its own digest, true for zchunk
as well as current rpm format.
___
devel mailing list --
Um, rpm headers are not compressed, so there is no decompression overhead
retrieving a tag value, and there is no reason why an entire rpm needs to be
decompressed in order to retrieve a value.
Presumably you are obliquely referring to deltarpm creation, not rpm tag value
access.
After
Why not Haskell?
Seriously: you provide no reason for rust other than that "C is not attractive".
C is surely a reliable implementation language for long running system services.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
To answer your question solely because I don't like FUD driven phears monger
int discussions
RPM based depsolvers select packages based on heuristics, including what is
already installed.
Any malicious package that had Provides: glibc would most likely be ignored
because glibc is already
There is no reason why a connection to an AMQP broker cannot be opened and
carried into a chroot that has networking disabled: rpm installs already
perform chroot's carrying multiple open Berkeley DB fdnos into the chroot.
___
devel mailing list --
Changing Fedora infrastructure to use AMQP brings up a different usage case.
Build systems tend to eventually invoke rpmbuild to do the actual build.
Would you like rpmbuild to, say, send time stamped progress messages directly
through AMQP?
The usage case for AMQP messages in rpmbuild starts
There is a further optimization for file dependencies not in some whitelist
that might be undertaken by depsolvers like dnf: lookup the path in the already
installed packages.
The fundamental need for depsolvers resolving a dependency is the ability to
traverse a mapping from path to package
Perhaps you do not understand the implications of "maintained" wrto a whitelist.
A cross repository file dependency should lead to a request to add a path or
pattern to a whitelist for the other repository to provide a file path, not to
a lazy download of megabytes of mostly unused data "just
My issue is the misdirection discussing lazy filelist downloading as a
"solution" to the "problem" of huge amounts of data that is forced to be
downloaded and loaded.
The issue has been discussed repeatedly without a solution.
Adding -- and maintaining -- patterns or whitelist exceptions,
> On Tue, Aug 07, 2018 at 08:50:25AM +, Michael Schroeder wrote:
>
> Yep, that sounds like an excellent idea.
>
>
> That's a good question. The time window where this can happen is not
> be that big, because without filelists the loading of metadata is
> quicker. But it's still non-zero, so
Sure extending the whitelist -- either through hard coded patterns or an actual
list -- obviates the need for downloading bloated file lists.
Those techniques simply move "useful" data out of file lists and into another
file, either primary.xml or a whitelist.
Patterns (and Provides: /path)
At the risk of again being banned from Fedora, I point out this thread from
2011, discussing/measuring various techniques for reducing the size of metadata
containing many file paths for Mandriva
http://rpm5.org/community/rpm-devel/.html
___
devel
Bloom filters have false positives that can lead to difficult to predict
behavior.
The core proble(s) being reported with file dependencies is the size of the
download, the cost of the load, and the size/number of copies one for each
location managed by dnf. These are all problems that are
Whether dnf does what yum does misses the point:
Lazy downloading of file dependencies did not work then and does not work now.
Here's why:
The fundamental decision made by depsolvers is what packages are "newer" and
need to be upgraded.
When _ANY_ commonly used package has a file dependency
Try
...
%check
%ifarch ppc64 ppc64p7
exit 0
%endif
...
My comments apply to the rest of what you appear to be proposing everywhere.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Yuck.
So you are recommending using 14 lines (with comments) of spec file goop that
uses 2 %ifarch build section tests in order to set/unset a macro.
There's further baggage in spec files needed to add a BR, pass an option to
configure, add libraries to link, etc
You are in the wrong
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
Don't rely on MODERATE or LOW distinctions to drop a package in FX+2.
Just drop all unfixed packages with the same policy.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
You are absolutely correct: there are times, e.g., that drinking coffee is
"more important" to me than say, replying to e-mail. However I don't think that
Haskel is the best language to feature up an already existing uglix tool.
Meanwhile I do not know of a tool that schedules rpm builds
There are easier ways to accomplish build ordering using tsort(1) and a minor
amount of scripting with the same simplifying assumptions your program is
making:
1) no cycles
2) every package provides its own name
3) every package supplies prerequisite package names without versions
tsort(1) just
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
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
Package renaming using Obsoletes/Provides will be a problem *ONLY* if
applications confuse the version of the package with the CRDB format version:
these are intrinsically different versions even if there is a single package
renaming event that is coincident with the CRDB format change.
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
There is also historical precedent in open source software for using the terms
"recommended" and "suggested" rather than "appropriate".
Installing/upgrading licensed software is never appropriate.
___
devel mailing list -- devel@lists.fedoraproject.org
Try "expected" rather than "appropriately"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
26 matches
Mail list logo
