Half a year later, there's still no fakechroot upstream release with the
relevant fix in it. Not exactly a huge surprise since the latest release is
from 2016.
We can reconsider when they finally cut that release. In the meanwhile, see my
earlier comment about nftw()...
--
You are receiving
There are significant differences between the glibc and the rpm copies of fts.:
they are different routines in the ABI even if they started from the same code
base, there are (at least) 4 extra pointers.
Arguing about "bloat" or proper use of libraries for routines that are
intrinsically
@ldv-alt - the thing is, a "use foo on glibc" kind of change doesn't really do
anything to get rid of the bundled code because it'll still be needed for other
platforms. Instead these things end up *adding* more burden by introducing
another path requiring validation. So when such a change
The other looming issue is stat(2), the new fangled stat replacement from David
Howells.
xstat(2) is going to require more significant changes to fts.c than LFS.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mhatle When I tried with pseudo, replacement was almost, but not quite,
seamless and drop-in.
I'll try to revisit the issues later this week ... it was more than a year ago
that I tried using pseudo.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@ldv-alt That's just rude.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/324#issuecomment-329169030___
Rpm-maint mailing
@pmatilai, you are a perfect marvel! Thank you for being so grateful to us for
getting rid of bundled X and fixing your buggy Z.
Thanks everybody for this enlightening discussion, I suppose no more comments
are needed here.
--
You are receiving this because you are subscribed to this thread.
fakechroot patch has been merged in upstream btw.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/324#issuecomment-329106933___
@mhatle Aside from that, @n3npq mentioned this:
> Almost everything Just Works ... the few tests failing can likely be fixed
> rapidly.
If you could provide a PR with the change and fixed the failing tests, I think
it'd be quite appreciated.
--
You are receiving this because you are
@Conan-Kudo patch for what? Generally speaking switching from
fakeroot/fakechroot to pseudo should be seamless... (simple search/replace)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mhatle Would you consider proposing a patch to switch from `fakechroot` to
`pseudo`? It looks like we have `pseudo` in Fedora, and if RPM's testsuite
depends on it, I can introduce packages for Mageia and openSUSE so that the
test suite can be run there.
--
You are receiving this because you
> Why should rpm ever want to walk a remote URI?
There are at least a couple of occasions where it does. RPM is capable of
installing packages from remote locations. It'll fetch the RPM and go through
the correct process to install the package as described by the user. I use this
all the time
I suppose I should donate copies of opendir/readdir/stat/lstat that "work" with
rpm Header's.
The world is littered with sloppy code trying to reconstruct stat(2)
information in custom code based on headerGet(). Using fts.c to bury all the
details of headerGet() is far easier to program with
@ldv-alt Rpm deals with many hierarchies, including files in
payloads/transactions, where fts.c is a convenient abstraction for traversal
when customized opendir et al are added.
Issues with current maintainer can at least be dealt with now that you have
added your complaints.
--
You are
@n3npq Why should rpm ever want to walk a remote URI?
Anyway, rpm.org doesn't need its copy of fts.c when linked with glibc >= 2.23,
and the bug is that
- rpm.org's maintainer is not ready to admit this fact and act accordingly;
- his attitude to contributors discourages further contributions.
The ability to replace opendir/readdir/stat/lstat permitted walking remote
URI's and are otherwise quite obvious changes.
Go ahead and show me how to use the glibc fts.c to walk remote URI's.
The other reason for internalizing fts.c was an incompatible change to how
symlinks were traversed
@n3npq I wish to get rid of fts.c completely, as well as all other stuff that
belongs to glibc.
I wish you haven't added that stuff in the first place! :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
If all you wish is RPM with LFS support, the changes to add LFS support are
quite minor, and are better addressed as a RFE, rather than an arch claim about
"fixes". Just saying ...
But where is LFS support needed these days?
--
You are receiving this because you are subscribed to this thread.
@pmatilai, how often do you sync your copy of fts.c with glibc?
I bet your fts.c doesn't have any fixes made in glibc since the last sync.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mhatle I've replaced fakechroot with pseudo its a couple of lines.
Almost everything Just Works ... the few tests failing can likely be fixed
rapidly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Instead of 'fakechroot', have you considered using 'pseudo'? It does support
large filesystems and other APIs.
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/
Both inside and outside of the OpenEmbedded work, we exclusively use pseudo to
replace 'fakeroot' and 'fakechroot' capabilities.
--
@pmatilai, upstream is looking on it btw.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/324#issuecomment-328453985___
Yeah it fails because fakechroot doesn't have LFS support - and looking at
upstream still doesn't. Fedora packages dont count.
Revisit when fakechroot upstream has a release that supports LFS, it's not like
there's any actual urgency in getting this change in.
--
You are receiving this
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/324#pullrequestreview-61663848___
I've tried to build with Fedora's fakechroot version:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21748556
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
…at doesn't handle LFS""
Test failure is bug in fakechroot.
This reverts commit 7e65bec67d7461ba37c10b8dcb1b892911c38ab1.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/324
-- Commit Summary --
* Revert "Revert "Only
26 matches
Mail list logo
