Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkgdiff-mg: can't cope with ruby-fakegem unpacked layout #21

Open
thesamesam opened this issue May 18, 2024 · 2 comments
Open

pkgdiff-mg: can't cope with ruby-fakegem unpacked layout #21

thesamesam opened this issue May 18, 2024 · 2 comments

Comments

@thesamesam
Copy link
Collaborator

pkgdiff-mg doesn't currently work for ruby-fakegem.eclass-based ebuilds because it compares the wrong paths, and all differences show up as new files.

(I don't know why this layout exists at the point of src_unpack or if that's optimal, though.)

For example, take d24600a71dade13abf890f10ae29a2d39302b68c in gentoo.git, and run pkgdiff-mg pg-1.5.{5,6}.ebuild.

We get a bunch of results like:

diff '--color=always' '--exclude=.git' --strip-trailing-cr -X - -dupNr /tmp/mgorny-dev-scripts/portage/dev-ruby/pg-1.5.5/work/all/ruby-pg-1.5.6/.travis.yml /tmp/mgorny-dev-scripts/portage/dev-ruby/pg-1.5.6/work/all/ruby-pg-1.5.6/.travis.yml
--- /tmp/mgorny-dev-scripts/portage/dev-ruby/pg-1.5.5/work/all/ruby-pg-1.5.6/.travis.yml        1970-01-01 01:00:00.000000000 +0100
+++ /tmp/mgorny-dev-scripts/portage/dev-ruby/pg-1.5.6/work/all/ruby-pg-1.5.6/.travis.yml        2024-03-01 18:15:55.000000000 +0000
@@ -0,0 +1,49 @@
+sudo: required
+dist: focal
+services:
+  - docker
+language: ruby
+matrix:
+  include:
+    # i386: Intel 32-bit
+    - name: i386
[...]

i.e. every file gets treated as brand new because we're comparing the wrong basepath on the LHS, as we don't realise that there's an extra layer within WORKDIR.

@thesamesam
Copy link
Collaborator Author

cc @graaff

Pretty sure I had a workaround for this ages ago but I've since lost/forgot about it.

@mgorny
Copy link
Member

mgorny commented May 18, 2024

I guess we'd have to use ${S}/${RUBY_S}?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants