Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)
On Sun, 4 Sep 2016, Neal Gompa wrote: The first thing to do on this way was to rebase many ALT's features[1] onto rpm(-install)-4.13. (Not yet features relevant for rpm-build.) [1] https://www.altlinux.org/Rpm-4.13 I looked through the wiki page and also the git repository on ALT Linux's gear for rpm-4.13[1], and there were some commits of concern: * git hash: 08677107ea8efb30099b05c0c9876e0cfdbd9799: Add support of ALT Linux traditional posttrans filetriggers - This commit is interesting because it's completely redundant. My understanding is that the legacy file triggers implementation in ALT Linux is derived from the original one developed by Mandriva. In I don't know enough about the history of it to tell this for sure. Mageia, we've ported all of the Mandriva style file triggers over to the system that's part of rpm 4.13, and we'd be happy to share with you guys the newer versions of these and help you guys get up to speed there. One issue is that the new rpm should be able to work with the old packages, published in the old distro branches, at least in order to enable an upgrade. Another one is that the rpm maintainer (like Gleb) can't rewrite the filetriggers in all the packages at once; rather he can provide the tool which implements the old and new features and wait for the maintainers of the packages who own the triggers to catch up; and ultimately, the old feature can be removed. I might be misunderstanding something about the mechanism. * git hash: 61a1aaa2c0795f8bd564bdbef2b45cc4f44902ac: Write to syslog about installed/removed packages - Why exactly is this necessary? This isn't a huge deal, but wouldn't apt handle this already? This also feels like it should be written as Some users invoke the bare rpm command. an rpm plugin rather than be a mandatory part of rpm. Other resolvers (like Yum/DNF and Zypper) do record this information already to some form of database/log which is accessible at any time, so it would be redundant in that case. What kind of plugin do you mean? * git hash: 4487281b1ed93cc8a997adb56be51c33c52ebce9: Add /usr/lib/rpm/macros.d/*, /etc/rpm/macros.d/* to macrofiles - This one seems weird, as it disables the *.attr files and eliminates the macros file name convention we've used in Fedora, CentOS, Mageia, and openSUSE. I suspect this patch will remain specific to ALT Linux. * git hash: 60ea90eeb0341c2f8c761133033cd3e015c082c7: Add scripts/find-package - I understand why this exists (apt metadata doesn't include file lists, so you can't resolve them). We have the same problem in Mageia with urpmi's hdlist2 metadata. We have patches that alter rpm's own find-requires script to work as you need it to so that you don't have to disable the internal generators. I've attached them to this email, with a "series" file to indicate the order in which the patches can be applied. These patches were written by Thierry Vignaud of Mageia for our rpm package to solve the same issue while leveraging the new dependency generator framework. Mageia's implementation is not in the upstream, too, is it? Which implementation is better: the Mageia's one or the ALT's one? I'll admit, I'm not really certain about many of the other ones... Perhaps someone else here can take a deeper review of some of the other patches and provide some feedback? Do you guys have an equivalent package to redhat-rpm-config[2] or rpm-mageia-setup[3] which contains your vendor configuration for RPM? It seems like some of this stuff (like the GROUPS file, macros, etc.) belong there... As for build-stage macros, many of them are maintained in separate language/compiler specific small packages rpm-build-* or rpm-macros-*, like rpm-build-python, rpm-build-python3, etc. [1]: http://git.altlinux.org/tasks/166699/gears/560/git?p=git;a=log [2]: http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/ [3]: http://gitweb.mageia.org/software/rpm/rpm-setup/about/ Best regards, Ivan ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)
On Sun, 4 Sep 2016, Neal Gompa wrote:
On Sun, Sep 4, 2016 at 7:28 AM, Ivan Zakharyaschev <i...@altlinux.org> wrote:
package in ALT Linux, and I was wondering if you guys had contemplated
upgrading from rpm 4.0.4 to rpm 4.13?
glebfm@ and legion@ are busy now with this.
https://lists.altlinux.org/pipermail/devel/2016-July/201603.html
They could give most details about this process.
The first thing to do on this way was to rebase many ALT's features[1] onto
rpm(-install)-4.13. (Not yet features relevant for rpm-build.)
[1] https://www.altlinux.org/Rpm-4.13
As said, there are a few ALT-specific nice, important and non-trivial
features in RPM, which would always require maintaining a separate fork
The list (published under the given link on the wiki) is quite long, and
Gleb has recently done a big job bringing them up-to-date with 4.13 (only
the rpm-install part, not the rpm-build one):
feature stage
pdeath_execute.c rpm
rpm --fancypercent rpm
filetriggers rpm
write installed/removed package buildtime to syslogrpm
enhanced rebuilding database messages rpm
rpm -q --lastchangerpm
rpm -q --changes-since=rpm
the '>'-test (required by changes-since) rpm
':nothing' format variant (required by changes-since) rpm
library set:versions comparison (install part) rpm
export RPM_INSTALL_{NAME,ARG1,ARG2} variables to scripts rpm
tools/rpm{ver,evr}cmp.crpm
syslog info message for {installed,removed} packages rpm
_wait_for_lock rpm
%homedir rpm
import language guessing mechanism from glibc/intl rpm
honor_buildtimerpm
rpm --ignorebuildtime rpm
disabled tsort presentation order rpm
alpha segments are always newer than numeric segments in rpm
versions/releases
use 'chmod -c' and 'chown -c -h' rpm
use posix_fadvise(2) to disable readahead rpm
do not exclude Requires(pre) dependencies from rpmdb index rpm
[epoch = (none)] != [epoch = 0]rpm
closeall.c both
/usr/lib/rpm/functions both
filesize.c rpmbuild
relative.c rpmbuild
GROUPS rpmbuild
%_bindir/gendiff rpmbuild
_configure_{script,target,update_config,...} rpmbuild
rpm -C rpmbuild
%_allow_root_buildrpmbuild
/usr/lib/rpm/.provides.sh rpmbuild
rpmbuild -bE, --nopatch, --nosourcerpmbuild
%check_def(), %def_with(), %def_without(), %def_enablerpmbuild
(), %def_disable(),...
verify_elf rpmbuild
%set_{autoconf,automake,libtool,gcc,...}_version rpmbuild
rpminitrpmbuild
nice_changerpmbuild
enhanced RPM_SCRIPTS_DEBUG support, implemented debug levels rpmbuild
enhanced RPM_SCRIPTS_DEBUG support, implemented debug levels rpmbuild
/usr/lib/rpm/setcmprpmbuild
find-debuginfo-files rpmbuild
add "-bt" %check-only option rpmbuild
library set:versions generation (build part) rpmbuild
buildhost macro defines package's buildhost tagrpmbuild
dump_ld_config rpmbuild
--
Best regards,
Ivan
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)
On Sun, 4 Sep 2016, Neal Gompa wrote: On Sun, Sep 4, 2016 at 7:28 AM, Ivan Zakharyaschev <i...@altlinux.org> wrote: package in ALT Linux, and I was wondering if you guys had contemplated upgrading from rpm 4.0.4 to rpm 4.13? glebfm@ and legion@ are busy now with this. https://lists.altlinux.org/pipermail/devel/2016-July/201603.html They could give most details about this process. The first thing to do on this way was to rebase many ALT's features[1] onto rpm(-install)-4.13. (Not yet features relevant for rpm-build.) I'm sorry, I'm not too familiar with ALT's rpm setup, what is rpm-install? Simply, there is the rpm-build part of RPM which is used to create files of RPM format; and the "other" part, the essential one, the tool of the administrator which takes an RPM file and installs it, etc. To distinguish this basic part from rpm-build, we have been calling it rpm-install sometimes. (Theoretically, they are not tightly connected, and any other tool could be used instead of the standard rpm-build to produce RPM files if you target a distro which uses rpm to install packages, to control their dependencies etc. So, if someone thinks that the language of spec-files is ugly--like me--one can think about creating an alternative tool to describe the packages in another language, but still submit them to the same distro; for example, I'm interested in the way nix packages are done, and sometimes I'm thinking about various proxies like a tool to build an RPM package from nix rules, but also other kinds of proxies, in order to make the current work in ALT Sisyphus and in NixOS closer and more suitable for exchanging packages, switching the sources of the "specs".) [1] https://www.altlinux.org/Rpm-4.13 like to see the ALT Linux rpm maintainer team be involved in upstream rpm.org development, as I'm sure your perspective would be valuable to ensure a vibrant ecosystem around rpm. As said, there are a few ALT-specific nice, important and non-trivial features in RPM, which would always require maintaining a separate fork unless they are taken up by another RPM project, say, the rpm-4.13 project. Then the forces could be joined. If any of you guys who know about the extra features of your variant of rpm can talk about them, it'd be great if they could bring them up in the rpm-ecosystem mailing list[3] to propose for them to be merged upstream into the rpm.org codebase. Florian Festi (the manager of the Thanks for the links! Let's look forward. One more small comment from me: in a sense, it would be a good moment now to merge some patches right after Gleb has rebased the features onto 4.13, so that there is no delta. If you are interested in the patches, of course, you can have a look in the Git repository in the linked task (in one of the linked posts) and ask the authors any questions, but I'd suggest to wait until it is committed to ALT Sisyphus; then, it would be in a more finalized state. http://git.altlinux.org/tasks/166699/ rpm project) is always interested in receiving patches for new features and such. Patches are accepted via rpm-maint mailing list[4] or GitHub[5]. Discussions can also occur on IRC on Freenode in #rpm-ecosystem and #rpm.org. Best regards, Ivan ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
