Re: [Comm-en] RPM in ALT Linux (4.0.4 vs 4.13)

Re: [Comm-en] RPM in ALT Linux (4.0.4 vs 4.13)

[Ivan Zakharyaschev]

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

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

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

Re: [Comm-en] 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 <imz@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

Re: [Comm-en] 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 <imz@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 syslog            rpm
enhanced rebuilding database messages                          rpm
rpm -q --lastchange                                            rpm
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.c                                        rpm
syslog info message for {installed,removed} packages           rpm
_wait_for_lock                                                 rpm

  %homedir                                                      rpm
import language guessing mechanism from glibc/intl             rpm
honor_buildtime                                                rpm
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_build                                            rpmbuild
/usr/lib/rpm/.provides.sh                                      rpmbuild
rpmbuild -bE, --nopatch, --nosource                            rpmbuild
  %check_def(), %def_with(), %def_without(), %def_enable        rpmbuild
(), %def_disable(),...
verify_elf                                                     rpmbuild
  %set_{autoconf,automake,libtool,gcc,...}_version              rpmbuild
rpminit                                                        rpmbuild
nice_change                                                    rpmbuild
enhanced RPM_SCRIPTS_DEBUG support, implemented debug levels   rpmbuild
enhanced RPM_SCRIPTS_DEBUG support, implemented debug levels   rpmbuild
/usr/lib/rpm/setcmp                                            rpmbuild
find-debuginfo-files                                           rpmbuild
add "-bt" %check-only option                                   rpmbuild
library set:versions generation (build part)                   rpmbuild
buildhost macro defines package's buildhost tag                rpmbuild
dump_ld_config                                                 rpmbuild

--
Best regards,
Ivan

Re: [Comm-en] 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