[Rpm-maint] [rpm-software-management/rpm] %defattr(644, root, root, 755) -> %_defaultdocdir gets perm 644 (#162)
There seems to be a weird regression in rpm 4.13.
If a package contains
```
%files
%defattr*644,root,root,755)
%doc README
```
then the file README is copied to %{_defaultdocdir}/%{name} as expected, but
said directory is assigned permission 644 (instead of 755). This used to work
correct with rpm 4.12
rpm 4.12:
```
rpm -qlvp test-0-0.x86_64.rpm
drwxr-xr-x2 rootroot0 Feb 20 23:13
/usr/share/doc/packages/test
-rw-r--r--1 rootroot 11 Feb 20 23:13
/usr/share/doc/packages/test/dummy
```
rpm 4.13:
```
rpm -qlvp test-0-0.x86_64.rpm
drw-r--r--2 rootroot0 Feb 20 23:19
/usr/share/doc/packages/test
-rw-r--r--1 rootroot 11 Feb 20 23:19
/usr/share/doc/packages/test/dummy
```
--
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/issues/162___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)
> @DimStar77 , > > > Just to chime in here as well: openSUSE has the 'distro bootstrap' split > > and tries to keep it under control. It's right that python3 is already in > > that chain (we build python3 is a minimal set with as few deps as possible, > > and an enhanced set, in two runs) > > I am curious, what depends on it apart from glibc (I guess)? so far, glibc is the only python3(base) consumer (and I was not happy when the started - but our arguments were dismissed by the glibc maintainers back then too) > > meson > > If you have Python, no other deps. Yep.. that does not sound scary (as long as one does not care for meson's test suite!) > > ninja > > Easy-peasy, C++. 'almost is everything turns out to be easy' - yet, one also wants to keep it small to get a bootstrap cycle. > > re2c > > Technically this is optional since ninja ships pre-generated sources. Definitively not what we aim for. vendored-in sources is the wrong solution to any problem. For the same reason as most distros stopped linking everything statically. Preferably, the goal is to eliminate something out of the ring for something else coming in. That would be the optimal case. The more there is in the bootstrap cycle, the worse it gets on ABI changs if you take care of a distro that's is self-contained -- 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/1209#issuecomment-625912336___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)
Just to chime in here as well: openSUSE has the 'distro bootstrap' split and tries to keep it under control. It's right that python3 is already in that chain (we build python3 is a minimal set with as few deps as possible, and an enhanced set, in two runs) I made a quick check as to what that would mean for our setip if rpm were to switch to meson. We'd need: * meson (obvious) * ninja * rec2c as new packages in ring0 (which currently consistes of 119 packages) -- 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/1209#issuecomment-625859974___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)
> That said, if people _really_ think Python is a problem, I'm all in favor of > CMake here. The rest of the package manager stack maintained in this > organization uses it. Heck, openSUSE's Zypper uses it! Weak argument: libzypp/zypper are not needed to bootstrap a distro (but we already have to build cmake twice anway to get out of a cycle due to cmake linking libcurl - but cmake further requries libuv and rhash) if I could choose, I'd prefer meson of cmake -- 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/1209#issuecomment-637522500___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
