Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)

[Neal Gompa]

On Sun, Sep 4, 2016 at 6:16 PM, Ivan Zakharyaschev  wrote:
>
> 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)

[Ivan Zakharyaschev]

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)

[Neal Gompa]

On Sun, Sep 4, 2016 at 12:23 PM, Ivan Zakharyaschev  wrote:
>
> 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)

[Ivan Zakharyaschev]

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):


   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)

[Ivan Zakharyaschev]

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.)



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)

[Neal Gompa]

On Sun, Sep 4, 2016 at 7:28 AM, Ivan Zakharyaschev  wrote:
> 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)

[Igor Gnatenko]

On Sun, Sep 4, 2016 at 1:28 PM, Ivan Zakharyaschev  wrote:
> 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