Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)
On Sun, Sep 4, 2016 at 6:16 PM, Ivan Zakharyaschevwrote: > > 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. That does make sense. Hopefully that will be properly communicated as the migration begins. Feel free to reach out to Mageia on the dev mailing list[1] if you'd like assistance on this. > >> * 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. > That's fair. >> 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? > RPM has a plugin architecture[2] which I think could implement what you're looking for. In fact, it looks like there already is a syslog plugin[3]. If it doesn't do all what you need, it might be worth extending it to emit the extra logging you want. >> * 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? > Our patches are not upstream because both Fedora and openSUSE use dependency resolvers that use rpm-md metadata, which supports file dependencies (so they don't need it). We're also going to support it in Mageia 6 with our implementation of DNF[4], but we still keep the patches up in order to support urpmi. In my opinion, Mageia's implementation is better because it leverages the modern dependency generators included in rpm 4.13. I'm not sure if file dependencies would work if you used rpm-md repository metadata with apt-rpm, since it does support the rpm-md repository metadata format. >> 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
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, Sep 4, 2016 at 12:23 PM, Ivan Zakharyaschevwrote: > > On Sun, 4 Sep 2016, Neal Gompa wrote: > >> On Sun, Sep 4, 2016 at 7:28 AM, Ivan Zakharyaschev >> 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): > 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 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. * 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 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. * 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. 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... [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/ -- 真実はいつも一つ!/ Always, there's only one truth! rpm-4.13-mga-nofiledeps-depgen-patches.tar.gz Description: GNU Zip compressed data ___ 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 Zakharyaschevwrote: 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 Zakharyaschevwrote: 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
Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)
On Sun, Sep 4, 2016 at 7:28 AM, Ivan Zakharyaschevwrote: > Hello! > > On Sat, 3 Sep 2016, Neal Gompa wrote: > >> I saw you guys listed as the most recent ones to change the rpm >> 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? > [1] https://www.altlinux.org/Rpm-4.13 > >> If so, why haven't you? What's holding you back from upgrading? I'd > > > Apart from the first important step (rebasing ALT's rpm-install) which has > been done and is ready for testing, there are things would hold us back from > putting the new version into ALT Sisyphus: > > those packages which use librpm and/or access RPM's db will have to be > adapted for the new version. (The first one, of course, is APT; then, there > are some Perl bindings actively used by the tools for automatic package > analysis, modification, submission; perhaps, some more, I don't know the > list of things that hold this back well, but other involved people could > tell you more.) > As for APT, the Debian guys are actually interested in working with RPM guys to integrate the backend into mainline APT. This would be a good time to kill two birds with one stone. Julian Klode (juliank) on #debian-apt on OFTC has already pulled in apt-rpm git master[1] and I've sent him a PR including patches from Fedora that make it work with RPM 4.13[2]. If you guys still want to pursue using APT for RPM instead of using something like DNF, then it'd be a great idea if you guys got involved in the effort to bring apt-rpm into the current apt master. The merge of the rpm backend feature will lead to the release of apt 2.0. I've been talking to Michael Vogt (mvo) and Julian Klode about it for a while now, and it'd be great to get some people who could help with making that merge happen. I'm somewhat surprised that there are still distros using apt-rpm by default, but if you guys like it and want to continue using it, I think it'd be great if you could help with getting it merged into the apt mainline codebase. >> 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. > > One of these features is the support for set-versions (the <= relation, > which is used to constrain Requires/Provides, which would behave not like a > linear order, but like inclusion of sets), developed by at@ in the past. > Now, he has announced that he is developing an enhanced varaint of this > feature and could tell the details about the current developments to those > who are interested. > (https://lists.altlinux.org/pipermail/devel/2016-July/201614.html : support > for prototypes/signatures similar to C++ mangling, but for C). > 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 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. > at@ has pointed to his new work at https://github.com/svpv/rpmss -- > https://lists.altlinux.org/pipermail/devel/2016-August/201701.html . At the > same time, at@ shared his belief that if there is some code in ALT's RPM > which was once written and works correctly since then, there will be no need > to put efforts into maintaining it; and so, he sees no justification in the > complex work of rebasing onto rpm-4.13 because this would not save us any > future efforts in maintaining ALT's RPM compared to the current situation. > (Zero efforts if the current code of RPM works correctly.) > I'm somewhat biased, I guess, but as one of the folks who works on rpm in Mageia, I personally prefer minimizing our delta with upstream so that there's a strong point of collaboration and when new versions arrive, we can take them in easily. And the rpm.org community is rather nice and helpful. > glebfm@ -- Gleb Fontengauer-Malinovskiy > > legion@ -- Alexey Gladkov > > at@ -- Alexey Tourbin > > community-en@lists -- a mailing list for the
Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)
On Sun, Sep 4, 2016 at 1:28 PM, Ivan Zakharyaschevwrote: > Hello! Hi, > > On Sat, 3 Sep 2016, Neal Gompa wrote: > >> I saw you guys listed as the most recent ones to change the rpm >> 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 > >> If so, why haven't you? What's holding you back from upgrading? I'd > > > Apart from the first important step (rebasing ALT's rpm-install) which has > been done and is ready for testing, there are things would hold us back from > putting the new version into ALT Sisyphus: > > those packages which use librpm and/or access RPM's db will have to be > adapted for the new version. (The first one, of course, is APT; then, there > are some Perl bindings actively used by the tools for automatic package > analysis, modification, submission; perhaps, some more, I don't know the > list of things that hold this back well, but other involved people could > tell you more.) > >> 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. Why don't you propose patches to RPM upstream? > > One of these features is the support for set-versions (the <= relation, > which is used to constrain Requires/Provides, which would behave not like a > linear order, but like inclusion of sets), developed by at@ in the past. > Now, he has announced that he is developing an enhanced varaint of this > feature and could tell the details about the current developments to those > who are interested. > (https://lists.altlinux.org/pipermail/devel/2016-July/201614.html : support > for prototypes/signatures similar to C++ mangling, but for C). > > at@ has pointed to his new work at https://github.com/svpv/rpmss -- > https://lists.altlinux.org/pipermail/devel/2016-August/201701.html . At the > same time, at@ shared his belief that if there is some code in ALT's RPM > which was once written and works correctly since then, there will be no need > to put efforts into maintaining it; and so, he sees no justification in the > complex work of rebasing onto rpm-4.13 because this would not save us any > future efforts in maintaining ALT's RPM compared to the current situation. > (Zero efforts if the current code of RPM works correctly.) > > glebfm@ -- Gleb Fontengauer-Malinovskiy > > legion@ -- Alexey Gladkov > > at@ -- Alexey Tourbin > > community-en@lists -- a mailing list for the community around ALT for > discussions in English > > -- > Best regards, > Ivan > > > ___ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem