[Rpm-maint] [Suse-patch] Revert provides as obsoletes behavior
Hi! I have had a look at the obsolete behavior topic from a RHEL perspective. I checked all obsoletes in RHEL 3, 4 and 5 against the same and the previous release and filtered all that match against provides. For the results see the attachments. Reading the problem descriptions I have the suspicion that the problem is not that obsoletes match against provides but that rpm uses the obsolete mechanism to do updates - to find the packages it needs to remove to be more precise. This was fine as long as obsoletes just matched against pkg names which is what the update should do, too. But with the "new" obsolete behavior updates and obsoletes are different and should uses different code paths. If this is true (I have to admit that I did not look into the code) fixing the update behavior would be the way to go IMHO and not altering the actually unrelated obsolete handling. Florian Festi kernel-2.4.21-47.EL.athlon obsoletes kernel-modules provided by kernel-smp-unsupported-2.4.21-47.EL.athlon kernel-2.4.21-47.EL.athlon obsoletes kernel-modules provided by kernel-smp-unsupported-2.4.21-47.EL.i686 kernel-2.4.21-47.EL.athlon obsoletes kernel-modules provided by kernel-unsupported-2.4.21-47.EL.athlon kernel-2.4.21-47.EL.athlon obsoletes kernel-modules provided by kernel-unsupported-2.4.21-47.EL.i686 kernel-2.4.21-47.EL.athlon obsoletes kernel-modules provided by kernel-hugemem-unsupported-2.4.21-47.EL.i686 kernel-2.4.21-47.EL.i686 obsoletes kernel-modules provided by kernel-smp-unsupported-2.4.21-47.EL.athlon kernel-2.4.21-47.EL.i686 obsoletes kernel-modules provided by kernel-smp-unsupported-2.4.21-47.EL.i686 kernel-2.4.21-47.EL.i686 obsoletes kernel-modules provided by kernel-unsupported-2.4.21-47.EL.athlon kernel-2.4.21-47.EL.i686 obsoletes kernel-modules provided by kernel-unsupported-2.4.21-47.EL.i686 kernel-2.4.21-47.EL.i686 obsoletes kernel-modules provided by kernel-hugemem-unsupported-2.4.21-47.EL.i686 cups-1.1.17-13.3.37.i386 obsoletes lpr provided by LPRng-3.7.4-28.2.i386 system-config-httpd-1.3.1-1.noarch obsoletes apacheconf provided by redhat-config-httpd-1.1.0-4.30.2.noarch system-config-printer-0.6.116.5-1.i386 obsoletes printconf provided by redhat-config-printer-0.6.47.3.31-1.i386 system-config-printer-gui-0.6.116.5-1.i386 obsoletes printconf-gui provided by redhat-config-printer-gui-0.6.47.3.31-1.i386 system-switch-mail-0.5.25-3.noarch obsoletes redhat-switchmail provided by redhat-switch-mail-0.5.20-1.noarch system-switch-mail-gnome-0.5.25-3.noarch obsoletes redhat-switchmail-gnomeprovided by redhat-switch-mail-gnome-0.5.20-1.noarch xemacs-sumo-20040818-2.noarch obsoletes ruby-mode-xemacs provided by xemacs-21.4.13-8.ent.1.i386 xorg-x11-Mesa-libGL-6.8.2-1.EL.13.36.i386 obsoletes Mesa provided by XFree86-Mesa-libGL-4.3.0-110.EL.i386 xorg-x11-devel-6.8.2-1.EL.13.36.i386 obsoletes Mesa-devel provided by XFree86-devel-4.3.0-110.EL.i386 xorg-x11-devel-6.8.2-1.EL.13.36.i386 obsoletes xpm-devel provided by XFree86-devel-4.3.0-110.EL.i386 xorg-x11-libs-6.8.2-1.EL.13.36.i386obsoletes xpm provided by XFree86-libs-4.3.0-110.EL.i386 xorg-x11-xauth-6.8.2-1.EL.13.36.i386 obsoletes mkxauth provided by XFree86-xauth-4.3.0-110.EL.i386 firefox-devel-1.5.0.9-10.el5.i386 obsoletes mozilla-devel provided by seamonkey-devel-1.0.3-0.el4.1.i386 libFS-devel-1.0.0-3.1.i386 obsoletes XFree86-devel provided by xorg-x11-devel-6.8.2-1.EL.13.36.i386 libFS-1.0.0-3.1.i386 obsoletes XFree86-libs provided by xorg-x11-libs-6.8.2-1.EL.13.36.i386 libICE-devel-1.0.1-2.1.i386obsoletes XFree86-devel provided by xorg-x11-devel-6.8.2-1.EL.13.36.i386 libICE-1.0.1-2.1.i386 obsoletes XFree86-libs provided by xorg-x11-libs-6.8.2-1.EL.13.36.i386 libSM-devel-1.0.1-3.1.i386 obsoletes XFree86-devel provided by xorg-x11-devel-6.8.2-1.EL.13.36.i386 libSM-1.0.1-3.1.i386 obsoletes XFree86-libs
Re: [Rpm-maint] [Suse-patch] Revert provides as obsoletes behavior
Florian Festi wrote: > Reading the problem descriptions I have the suspicion that the problem is > not that obsoletes match against provides but that rpm uses the obsolete > mechanism to do updates - to find the packages it needs to remove to be > more precise. This was fine as long as obsoletes just matched against pkg > names which is what the update should do, too. But with the "new" obsolete > behavior updates and obsoletes are different and should uses different > code paths. > If this is true (I have to admit that I did not look into the code) fixing > the update behavior would be the way to go IMHO and not altering the > actually unrelated obsolete handling. After having a look at the code it is quite clear what's the problem here: The first line is causing most of the problems as it treats the updated package like an obsolete on its own name. This is obviously bullshit as rpm -U foobar should only remove packages named foobar and packages explicitly obsoleted by the new package. The python case mentioned earlier is a good example for that. In opposite the posting from Michael Schroeder I want to argue that matching real obsoletes against provides (second modified line of the patch) is the right thing (tm). If a package wants to replace a capability it should not need to know what packages anywhere (think of 3rd party repositories) do also provide that. I also don't see a problem that this might break other dependencies because they are all checked and the new package would be rejected with unresolved dependencies if it doesn't fix these problems. Of course is it still true that obsoletes are dangerous and need to be handled with care but this is an packaging issue... Florian Festi ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [Suse-patch] Revert provides as obsoletes behavior
Michael Schroeder wrote: On Tue, Jun 12, 2007 at 04:06:44PM +0200, Tomas Mraz wrote: That's really debatable as the provides is M:N relationship - a package A might provide many virtual provides and after this update some of these provides might not be provided anymore by any package. So it surely can be argued both ways. Yes, but that's exactly the point that I was trying to make: the same is true for explicit obsoletes, so it does not make much sense to treat them differently. IMHO it should either be both look at the provides or neither, for consistency reasons. But I also agree that just disabling the provides for the implicit obsoletes solves most of the problems. I strongly disagree with this argumentation. Let's assume matching (real) obsoletes against provides is the wanted behavior - for whatever reason. Why updates should not be treated as obsoletes of the pkg name can be easily seen at the example already mentioned earlier. python-2.4 (virtual provides python = 2.4) python22 provides python = 2.2 rpm -Uvh python-2.5-1.rpm removes both of the packages above. The point here is that if someone builds a compat package this packages has to provide the regular package name with the old version - this is the purpose of the package. If updates match on the provides these packages will always be removed on updating the original package. This makes the purpose of the compat package - surviving an update to a new version - inexistent. Because compat packages are an important use cases and there is no way to get around this by clever packaging this behavior is a bug in rpm IMHO. Florian Festi ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Should installed obsoletes be seen as conflicts
Hi! While discussing the yum resolver I realized that I was erroneously believing that rpm would treat installed obsoletes like conflicts. Scenario: foo obsoletes: bar foo is installed rpm -ivh bar.rpm Right now rpm installs bar without any error. According to Panu apt-rpm issues an error here. Is it possible that rpm did issue an error in some earlier versions? And what is the right(tm) behavior? I have the feeling that just installing the obsoleted package is wrong. Of course changing the behavior should not be done for an maintenance release. So are there any plans for a major release yet? Florian Festi ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Should installed obsoletes be seen as conflicts
Peter Bowen wrote: On Wed, 2007-06-27 at 12:04 +0200, Florian Festi wrote: While discussing the yum resolver I realized that I was erroneously believing that rpm would treat installed obsoletes like conflicts. Scenario: foo obsoletes: bar foo is installed rpm -ivh bar.rpm Right now rpm installs bar without any error. According to Panu apt-rpm issues an error here. Is it possible that rpm did issue an error in some earlier versions? And what is the right(tm) behavior? Nope, this has been like this for ages. If you want it to conflict, add a conflict: bar to foo. Also, it should be noted that you can do: foo 2.0 is installed rpm -ivh foo-1.0.rpm Yes, you have to pass --oldpackage, but it works otherwise. Maybe --oldpackage should be required if you try to install a package that is obsoleted? Of course no one wants to make it impossible to install obsoleted packages. I agree that this situation is much closer to installing an old package than having a conflict (especially since obsoletes match package names only now and conflicts match provides). An obsoleted package in fact is an older version with an different name. So requiring --oldpackage makes perfect sense IMHO. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Pruning self-dependencies?
Panu Matilainen wrote: On Mon, 2 Jul 2007, Ville Skyttä wrote: As for how many dependencies this would eliminate, running some quick queries [0] against the Fedora primary sqlite metadata database told me it'd be about 7.3% of all dependencies (9246/126066). This is inaccurate (no versions in dependencies taken into account etc) but I think it should be the correct order of magnitude. Actually much of the benefit would be gained by just having createrepo drop self-requires out of the metadata. That would have an immediate benefit without requiring rebuilding the world. Of course you'd still be downloading the dependency bloat in the rpm's themselves but now that yum uses it's own depsolver doing this one the metadata level would already be beneficial. - Panu - Except of a potential C vs Python issue I see no reason why that should be the easier solution. Implementing it in rpmbuild would grant this benefit for everyone and not only yum users. Rpmbuild also has a much better chance to keep manually added requires. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] yum/rpmlib timings: 1000 vs 9000 packages
Hi!
As already announced on #yum I am currently playing with really big
installations: F8 Everything everything
I now have timed various sub tasks in the preprocessing phase of rpmlib.
This gives a quite good idea where the problems are. Some of them need to be
fixed in yum others in rpm(lib).
The two test candidates are both fresh installs into an installroot on a
Fedora 8 machine using yum HEAD and rpm HEAD. One does a group install
resulting in about 1k packages ("Office/Productivity" "GNOME Desktop
Environment" "Games and Entertainment" "Sound and Video" "Development Tools"
"Graphical Internet" "System Tools" Core Base Editors Java "X Window System"
Graphics Ruby "KDE (K Desktop Environment)" ) and the second installs "*",
excludes 3 packages to resolve conflicts and uses the new --skip-broken
feature to get a working set of packages. This results in 8.9k packages.
All timings are in seconds (if not stated otherwise). I also give the ratio
of the timing to make spotting the runtime behavior easier.
Have fun
Florian
(Timings in seconds)
yum groupinstall ...
=
1007 pkgs
143,305 files
Depsolving 23.7
Running rpm_check_debug
populateTs 4.4871840477
check 0.353991985321
Running Transaction Test
initActionTs 0.0228180885315
populateTs 4.14678096771
test 25.1478779316
Finished Transaction Test
Transaction Test Succeeded
initActionTs 0.000195026397705
populateTs 4.15238595009
check 0.357394933701
order 0.437646150589
Running Transaction - not timed, see "test"
sum (with test counted twice): 1m28s
real1m35.466s (including install of 10 pkgs)
yum install *
=
8862 pkgs
1,413,118 files
Depsolving - 178.0
Running rpm_check_debug
populateTs 322.944131136
check 2.16476297379
Running Transaction Test
initActionTs 0.225929021835
populateTs 346.730643034
test 3151.71939611
Finished Transaction Test
Transaction Test Succeeded
initActionTs 0.220103979111
populateTs 513.005566835
check 2.37508201599
order 52.159758091
Running Transaction - not timed, see "test"
sum (with test counted twice): 128m43s
real138m17.627s (including install of 323 pkgs)
Ratio (install * / groupinstall)
pkgs: *8.8 (square: 77)
files: *9.9 (square: 97)
Running rpm_check_debug
populateTs *72
check *6.1
Running Transaction Test
initActionTs *9.9
populateTs *84
test *125
Finished Transaction Test
Transaction Test Succeeded
initActionTs *9.6
populateTs *124
check *6.6
order *119
Running Transaction - not timed, see test
sum (with test counted twice): *117
real *87 (ehm, forget about that)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] File fingerprinting
Hi!
I had some look into the file fingerprinting code. The purpose of this
code is to find file conflicts. The main problem it has to solve is the
fact that a file can be visible at different place in the directory tree
if there are symlinks pointing to any of the parent directories. To
solve this it does check for identical fingerprints of all files with
the same basename.
A finger print consists of the device and inode number of the parent
directory and if this directory doesn't exist yet the finger print of
that down most directory that does exist and the path from that
directory to the file.
Finger prints are used for two things:
1. Check all files in the transaction against each other
To do that the finger prints of all files in the transaction are put
into a big hash table.
2. Check the files in the transaction against those in the rpmdb
For each pkg:
For each file:
search the db for files with the same basename and create the
fingerprints for them
Finger printing actually doesn't work as soon as there are some symlinks
involved that are not installed yet. I attached 3 spec files that show that.
Install the README rpm that then install FOO and FOO-DOC at once. As you
can see /usr/share/README-1/README gets over writen without warning.
If README and FOO are already installed installing FOO-DOC raises an
error as expected.
The packages contain:
README: /usr/share/README-1/README
FOO: /usr/share/FOO-1 -> README-1
FOO-DOC: /usr/share/FOO-1/README
The 2. part is also quite inefficient as it checks the same basename
over and over again for each pkg containing a file with the same
basename (Good candidates are README, Copying, ...). This leads to a
kind of quadratic runtime behavior (installed files * to be installed
files with the same basename). To get rid of this the file finger prints
need to be checked for the whole transaction and not only per pkg. This
requires changing the data structures involved (pointing back from the
installed files to the "to be installed files") and reversing the way
the files are traversed.
This will require that we keep all matching files in memory at once. As
they can be represented (pkg num, file num) + (*pkg, file num) of the to
be installed pkgs this should be possible in a few dozen bytes per file
which means a few MB for some 100,000 files.
Florian
Summary: Test rpm performance for common base names
Name: README
Version: 1
Release: 1
License: GPLv2+
Group: Misc
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
%description
Install one README file
%prep
%build
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p -m 0755 $RPM_BUILD_ROOT/%{_datadir}/%{name}-%{version}
echo "This is a small test package to test performance of rpm when installing a file with a common basename" > $RPM_BUILD_ROOT/%{_datadir}/%{name}-%{version}/README
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc
/usr/share/README-1
/usr/share/README-1/README
%changelog
* Tue Apr 15 2008 <[EMAIL PROTECTED]> - Florian Festi
- Initial build.
Summary: Test rpm performance for common base names
Name: FOO
Version: 1
Release: 1
License: GPLv2+
Group: Misc
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
%description
%prep
%build
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p -m 0755 $RPM_BUILD_ROOT/%{_datadir}/
ln -s README-1 $RPM_BUILD_ROOT/%{_datadir}/%{name}-%{version}
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc
/usr/share/*
%changelog
* Tue Apr 15 2008 <[EMAIL PROTECTED]> - Florian Festi
- Initial build.
Summary: Test rpm performance for common base names
Name: FOO-DOC
Version: 1
Release: 1
License: GPLv2+
Group: Misc
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
Requires: FOO
%description
%prep
%build
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p -m 0755 $RPM_BUILD_ROOT/%{_datadir}/FOO-%{version}
echo "Oh dear!" > $RPM_BUILD_ROOT/%{_datadir}/FOO-%{version}/README
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc
/usr/share/FOO-%{version}/README
%changelog
* Tue Apr 15 2008 <[EMAIL PROTECTED]> - Florian Festi
- Initial build.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] rpm --aid problem
holmes86 wrote: Appear error message "Failed dependencies" When I install rpm package with --aid option under FC8. why? Don't do that. --aid is no longer supported (the database used to resolve the dependencies is no longer shipped) and this feature is not working well anyway and will removed from future versions of rpm. Use "yum install foo" instead. Yum is working on the packages actual available and is able to download them on demand. It is also possible to give rpm files to the yum command line. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Shortcut on desktop
aneeskA wrote: Hi all, Yet another question regarding placing a shortcut on the desktop of the user who is installing the package. While writing the spec file I found out that you can use the environment variable $HOME in %install section. But when it comes to listing the files in the distribution in the %files section, i cant use the $HOME. any one has any idea how can i do that so that i can copy a *.desktop file to the user's desktop which will ultimately solve my problem. Any help highly appreciated. There is a very simple reason why this is not possible: Linux is a multiuser system. What ever problem you are trying to solve putting files into the user directorIES is not the solution. Even if you could put a file "on the desktop of the user who is installing the package" it would end on the desktop of the "root" user. So you won't win anything with this approach. Consider putting a short cut into the Applications menu or describe the problem you are actually interested in more detail. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Shortcut on desktop
aneeskA wrote:
Hi Florian,
First of all thanks for replying. I will try to explain the
situation clearly.
You would have noticed that while installing RPMs like adobe
reader after the processing is complete he puts a shortcut on the
desktop and also one entry in Applications->Office. Looking at some of
the spec files I have found out that it is possible to duplicate the
same by placing a /*.desktop/ file on to //usr/share/applications
/folder. But it is not working for me. Also i had already figured out
that putting the file on to the desktop will end up in root's desktop.
Thats why i was looking for other alternatives. The only possible way
i can figure out is to place the /*.desktop /file on to some directory
which is used for such purposes. But //usr/share/applications/ /is
failing in my case.
If you can provide me with some inputs it will be great. I think I
have explained the situation vividly.
While I am not an expert in packaging desktop applications the few
packages I looked at call "update-desktop-database
%{_datadir}/applications" in their %post and %postun sections. May be
this is sufficient to make your short cut show up.
Florian
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade/replace multiple packages with custom package
Andy Harrison wrote:
Everything looks great at this point, but when I actually run the rpm
upgrade command, it complains that my package has files that conflict
with the currently installed openldap packages. I put in Obsoletes
lines for every package and version to be replaced (expressed this way
just for brevity: Obsoletes:
openldap-{servers,clients,devel,servers-sql} <= 2.4) to no avail.
If you set the obsolete right it should work. Make sure to run rpm -U
and not rpm -i
Why don't you just modifiy the original source rpms? This would make it
much more difficult for errors to sneak in.
Florian Festi
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Scalability of RPM
Hi Christoph, I am currently working on the scalability issues in rpm. Unfortunately they are not very easy to fix. Huge numbers of files and large numbers (>1000) of files with the same base name trigger these problems. If you have a different situation I would be very interested how it looks like. You can try if the rpm versions in Fedora 9 or even Fedora 10 alpha work better for you. There have been a lot of bug fixes including fixes for memory problems/leaks. But the main scalability problem is still unsolved. Backup your rpmdb (/var/lib/rpm) and then delete /var/lib/rpm/__db.* (temporary files that depend on the exact version of rpm/the bsddb) Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Re: %post-script prerequisites
Michael Schroeder wrote: On Thu, Sep 25, 2008 at 02:37:27PM +0200, Pixel wrote: Michael Schroeder <[EMAIL PROTECTED]> writes: So A requires B and B has a requires(post) to A? This isn't installable at all, thus it's a packaging bug. i don't agree. not knowing exactly what rpmlib does, here is how i understand the pb: "Requires" is same as "Requires(postrans)", ie if A requires B, it doesn't mean B must be installed before A. It means that B must be installed before A *works* (easiest case: B is a library). Thus, if C has a "Requires(post): A" (e.g. C calls A in a post scriptlet), A must work, so B and A have to be installed before C. Which brings us into the world of dependency loops and especially of dependency loops containing Requires(pre). Happy night mares Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] unexpected file conflict behavior
steven chen wrote: > Hi, > > Good day. > Recently I had a weird situation where I can install two rpms together (in > one line) without any errors but once I install them one after the other, I > got a file conflict errors. When looking closedly, the files that complain > about conflicting are actually owned by both packages. > Can anyone please shed some lights on me why installing them together will > work? (I actually expect to see file conflict error there too). > Thanks in advance. To fix that file conflict the files in the both packages need to be exactly the same (md5, owner, group, ...). As this is sometimes difficult to achieve for a multilib situation (as this) this test was lowered in the dark ages so that at least most installations will somehow work. This is of course nonsense and has already be changed back in rpm upstream (>=4.6). So not issuing an file conflict is an (already fixed) bug in rpm. While some of these multilib file conflicts are packaging bugs it is also possible that this conflict just tells you to install only one architecture of this devel package. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH] New file conflict check implementation
Hi!
I've been working on reimplementing the way files from the transaction
are checked against the rpmdb. This used to be done per package. This
has disadvantages for the rare cases that packages in both the ts and
the rpmdb share files with the same basename. This patch set generates a
global list of all files in the rpmdb with the basenames from the
transaction. This makes sure we load each package from the rpmdb only once.
To be able to do that I extended the rpmhash datatype to also work as a
set and exposed some functions from the rpmdb to the API. The first one
adds some more uglyness to a already ugly and complicated part, but the
only alternative would be to copy the code and then do the adjustments
(more or less just deleting stuff). For the additional functions from
the rpmdb it might be worth cnsidering moving them into rpmdb_internal.h
- comments and opinions are welcome.
There are still some rough edges like missing comments, poor commit
messages and missing disaster handling. So if it breaks you keep the
pieces. Nevertheless - comments are welcome.
Florian
>From 96bd6e1d548f1baf914cc5637b3f2b7292087042 Mon Sep 17 00:00:00 2001
From: Florian Festi <[EMAIL PROTECTED]>
Date: Wed, 5 Nov 2008 15:11:55 +0100
Subject: [PATCH] Support leaving HTDATATYPE undefined to use hash as key only hash (set)
---
lib/rpmhash.C | 35 +++
lib/rpmhash.H | 20 +---
2 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/lib/rpmhash.C b/lib/rpmhash.C
index a631074..907ea86 100644
--- a/lib/rpmhash.C
+++ b/lib/rpmhash.C
@@ -15,8 +15,10 @@ typedef struct Bucket_s * Bucket;
*/
struct Bucket_s {
HTKEYTYPE key; /*!< hash key */
+#ifdef HTDATATYPE
HTDATATYPE * data; /*!< pointer to hashed data */
int dataCount; /*!< length of data (0 if unknown) */
+#endif
Bucket next; /*!< pointer to next item in bucket */
};
@@ -28,7 +30,9 @@ struct HASHSTRUCT {
hashFunctionType fn; /*!< generate hash value for key */
hashEqualityType eq; /*!< compare hash keys for equality */
hashFreeKey freeKey;
+#ifdef HTDATATYPE
hashFreeData freeData;
+#endif
};
/**
@@ -54,7 +58,11 @@ Bucket HASHPREFIX(findEntry)(HASHTYPE ht, HTKEYTYPE key)
HASHTYPE HASHPREFIX(Create)(int numBuckets,
hashFunctionType fn, hashEqualityType eq,
- hashFreeKey freeKey, hashFreeData freeData)
+ hashFreeKey freeKey
+#ifdef HTDATATYPE
+, hashFreeData freeData
+#endif
+)
{
HASHTYPE ht;
@@ -62,13 +70,19 @@ HASHTYPE HASHPREFIX(Create)(int numBuckets,
ht->numBuckets = numBuckets;
ht->buckets = xcalloc(numBuckets, sizeof(*ht->buckets));
ht->freeKey = freeKey;
+#ifdef HTDATATYPE
ht->freeData = freeData;
+#endif
ht->fn = fn;
ht->eq = eq;
return ht;
}
-void HASHPREFIX(AddEntry)(HASHTYPE ht, HTKEYTYPE key, HTDATATYPE data)
+void HASHPREFIX(AddEntry)(HASHTYPE ht, HTKEYTYPE key
+#ifdef HTDATATYPE
+, HTDATATYPE data
+#endif
+)
{
unsigned int hash;
Bucket b;
@@ -82,20 +96,24 @@ void HASHPREFIX(AddEntry)(HASHTYPE ht, HTKEYTYPE key, HTDATATYPE data)
if (b == NULL) {
b = xmalloc(sizeof(*b));
b->key = key;
+#ifdef HTDATATYPE
b->dataCount = 0;
- b->next = ht->buckets[hash];
b->data = NULL;
+#endif
+ b->next = ht->buckets[hash];
ht->buckets[hash] = b;
}
+#ifdef HTDATATYPE
b->data = xrealloc(b->data, sizeof(*b->data) * (b->dataCount + 1));
b->data[b->dataCount++] = data;
+#endif
}
HASHTYPE HASHPREFIX(Free)(HASHTYPE ht)
{
Bucket b, n;
-int i, j;
+int i;
for (i = 0; i < ht->numBuckets; i++) {
b = ht->buckets[i];
@@ -107,14 +125,17 @@ HASHTYPE HASHPREFIX(Free)(HASHTYPE ht)
do {
n = b->next;
+#ifdef HTDATATYPE
if (b->data) {
if (ht->freeData) {
+ int j;
for (j=0; j < b->dataCount; j++ ) {
b->data[j] = ht->freeData(b->data[j]);
}
}
b->data = _free(b->data);
}
+#endif
b = _free(b);
} while ((b = n) != NULL);
}
@@ -132,6 +153,8 @@ int HASHPREFIX(HasEntry)(HASHTYPE ht, HTKEYTYPE key)
if (!(b = HASHPREFIX(findEntry)(ht, key))) return 0; else return 1;
}
+#ifdef HTDATATYPE
+
int HASHPREFIX(GetEntry)(HASHTYPE ht, HTKEYTYPE key, HTDATATYPE** data,
int * dataCount, HTKEYTYPE* tableKey)
{
@@ -159,7 +182,9 @@ void HASHPREFIX(PrintStats)(HASHTYPE ht) {
int buckets = 0;
for (bucket=ht->buckets[i]; bucket; bucket=bucket->next){
buckets++;
+#ifdef HTDATATYPE
datacnt += bucket->dataCount;
+#endif
}
if (maxbuckets < buckets) maxbuckets = buckets;
if (buckets) hashcnt++;
@@ -171,3 +196,5 @@ void HASHPREFIX(PrintStats)(HASHTYPE ht) {
fprintf(stderr, "Values: %i\n", datacnt);
fprintf(stderr, "Max Keys/Bucket: %i\n", maxbuckets);
}
+
+#endif
diff --git a/
[Rpm-maint] [Press release] RPM version 4.6.0 is out
Friday 6th of January 2009 RPM version 4.6.0 was released. The primary focus on this release has been cleaning up the code-base to make it more maintainable and robust, and also more approachable to invite more community involvement. Code duplications, memory handling and various code pieces have been cleaned up. The local copies of system libraries like db4, lua, popt and libmagic were removed. New APIs have been established and dozens of old bugs have been fixed. A several obsolete features have been removed from the code base. There also have been a number of visible improvements. Some of the more notable include: * Subpackages of architecture dependent packages can now be noarch. This allows to share language, documentation or data subpackages among different architectures. * Support for packages > 2GB (up to 64 bit sizes). Right now packaged files are still restricted to 4GB due to limitations of cpio. * Support for secure file checksums such as SHA256 and SHA512 as a replacement for MD5. * Improvements for package builders like better support for building packages as non root and better access to patches and sources in the spec files. Full release notes can be found at http://rpm.org/wiki/Releases/4.6.0 For a more comprehensive explanation of the most important changes see http://rpm.org/wiki/Releases/4.6.0#Compatibilitynotes We want to thank Mandriva Linux and the Fedora Project for their testing efforts of the 4.6.0 release candidates as parts of their distributions. The RPM development team ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] RPM at the Linux Tag 2009 in Berlin
Hi! I am going to give a talk about what's going on in RPM development at the Linux Tag in Berlin. Although the talk is going to be part of the FudCon and though some minor parts will be Fedora specific it will target everyone interested in RPM. Talk is scheduled for Saturday 16:00[1]. Jinrich Novy will also be around. Additionally to the talk and the discussion afterwards I would love to meet RPM/packaging related people from the various RPM based distributions. Things are still moving fast and I'd like to get a personal impression how people feel about it and what areas deserve to be targeted in the future. Fell free to announce where you can be found during Linux Tag here or drop me a private mail. Florian Festi [1] https://fedoraproject.org/wiki/FUDCon:Berlin_and_LinuxTag_2009_talks ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] restricting content in spec files/pkgs to unicode only
On 07/23/2009 10:35 PM, Seth Vidal wrote: Hi, Looking at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=513459 got me thinking - would it be possible to have rpmbuild check all the content it is going to put into the rpm header to see if it is unicode decodable and abort if it is not? It would save anyone handling it from w/i python a lot of pain and suffering, I think. Would it be possible? No, files can have any 8 bit name. They should be utf-8 but this is not guaranteed. Sorry... Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH] RPMDB Performance
Hi!
I've done a couple of performance measurements around the rpmdb. It
turns out that the huge number of f(data)sync calls is significantly
slowing down RPM on todays ext[234] file systems.
Setting no_fsync in the rpmdb config drops the F10 Everything install
--justdb from 2:51:00 to 4:50. The install without --justdb drops from
5:38h to 1:20h (All with hot FS caches on my new desktop).
As my first two attempts (setting other config parameter as cache_size
etc and using db4 transactions) have failed the attached patch does now
switch off fsync for building the rpmdb indexes only. I don't have
access to my desktop computer right now, but --justdb now takes 26:29
instead of 11:21 with no_fsync on my (much slower) laptop. Nevertheless
building the rpmdb with fsync enabled also takes 2:54h which indicates
that it is primarily limited by the turning speed of the hard disk which
seems to be the same on my laptop and desktop.
The patch still needs better integration into the rpmdb configuration
system and dummy code for the sqlite backend.
Any thoughts or safety concerns?
Florian
>From ff94cad6a0e6d289aa2361329b63a477fe5d0ae5 Mon Sep 17 00:00:00 2001
From: Florian Festi
Date: Wed, 5 Aug 2009 15:42:11 +0200
Subject: [PATCH] Switch off fsync while editing the indexes of the rpmdb
---
lib/backend/db3.c |7 ++-
lib/backend/dbconfig.c |4
lib/rpmdb.c| 23 +++
lib/rpmdb.h|2 ++
lib/rpmdb_internal.h |2 ++
5 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/lib/backend/db3.c b/lib/backend/db3.c
index 9f0f941..31b8051 100644
--- a/lib/backend/db3.c
+++ b/lib/backend/db3.c
@@ -196,6 +196,11 @@ static int db3_fsync_disable(int fd)
return 0;
}
+static int db3switchfsync(int on)
+{
+return db_env_set_func_fsync(on ? fdatasync : db3_fsync_disable);
+}
+
#if (DB_VERSION_MAJOR >= 4 && DB_VERSION_MINOR >= 5)
/*
* dbenv->failchk() callback method for determining is the given pid/tid
@@ -1123,6 +1128,6 @@ static int db3open(rpmdb rpmdb, rpmTag rpmtag, dbiIndex *
dbip)
RPM_GNUC_INTERNAL
const struct _dbiVec db3vec = {
DB_VERSION_MAJOR, DB_VERSION_MINOR, DB_VERSION_PATCH,
-db3open, db3close, db3sync, db3copen, db3cclose, db3cdel,
+db3open, db3close, db3sync, db3switchfsync, db3copen, db3cclose, db3cdel,
db3cget, db3cput, db3ccount, db3byteswapped, db3stat
};
diff --git a/lib/backend/dbconfig.c b/lib/backend/dbconfig.c
index e668036..cf678d1 100644
--- a/lib/backend/dbconfig.c
+++ b/lib/backend/dbconfig.c
@@ -429,6 +429,10 @@ dbiIndex db3New(rpmdb rpmdb, rpmTag rpmtag)
dbi->dbi_cachesize = 1 * 1024 * 1024;
}
+if (rpmtag != RPMDBI_PACKAGES) {
+ dbi->dbi_no_dbsync = 1;
+}
+
if ((dbi->dbi_bt_flags | dbi->dbi_h_flags) & DB_DUP)
dbi->dbi_permit_dups = 1;
diff --git a/lib/rpmdb.c b/lib/rpmdb.c
index 1f1c545..7b61f97 100644
--- a/lib/rpmdb.c
+++ b/lib/rpmdb.c
@@ -882,6 +882,13 @@ int rpmdbSync(rpmdb db)
return rc;
}
+int rpmdbSwitchFsync (rpmdb db, int on)
+{
+assert(db->_dbi[0]);
+assert(db->_dbi[0]->dbi_vec);
+return db->_dbi[0]->dbi_vec->switchfsync(on);
+}
+
/* FIX: dbTemplate structure assignment */
static
rpmdb newRpmdb(const char * root,
@@ -2495,6 +2502,7 @@ int rpmdbRemove(rpmdb db, int rid, unsigned int hdrNum,
sigset_t signalMask;
int ret = 0;
int rc = 0;
+int xx;
if (db == NULL)
return 0;
@@ -2523,6 +2531,8 @@ int rpmdbRemove(rpmdb db, int rid, unsigned int hdrNum,
}
(void) blockSignals(&signalMask);
+xx = rpmdbSwitchFsync(db, 0);
+assert(xx==0);
/* FIX: rpmvals heartburn */
{ int dbix;
@@ -2543,6 +2553,9 @@ int rpmdbRemove(rpmdb db, int rid, unsigned int hdrNum,
continue;
if (rpmtag == RPMDBI_PACKAGES) {
+ xx = rpmdbSwitchFsync(db, 1);
+ assert(xx==0);
+
dbi = dbiOpen(db, rpmtag, 0);
if (dbi == NULL)/* XXX shouldn't happen */
continue;
@@ -2565,6 +2578,8 @@ int rpmdbRemove(rpmdb db, int rid, unsigned int hdrNum,
dbcursor = NULL;
if (!dbi->dbi_no_dbsync)
xx = dbiSync(dbi, 0);
+ xx = rpmdbSwitchFsync(db, 0);
+ assert(xx==0);
continue;
}
@@ -2659,6 +2674,9 @@ cont:
rec = _free(rec);
}
+xx = rpmdbSwitchFsync(db, 1);
+assert(xx==0);
+
(void) unblockSignals(&signalMask);
h = headerFree(h);
@@ -2771,6 +2789,9 @@ int rpmdbAdd(rpmdb db, int iid, Header h,
if (hdrNum)
{
+ int xx;
+ xx = rpmdbSwitchFsync(db, 0);
+ assert(xx==0);
dbiIndexItem rec = dbiIndexNewItem(hdrNum, 0);
if (dbiTags.tags != NULL)
@@ -2949,6 +2970,8 @@ cont:
if (ret == 0)
Re: [Rpm-maint] [PATCH] RPMDB Performance
On 08/11/2009 12:47 PM, devzero2000 wrote: On Tue, Aug 11, 2009 at 12:19 PM, Florian Festi<mailto:ffe...@redhat.com>> wrote: > Any thoughts or safety concerns? Beware of data loss with ext4 dropping down fsync http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892 The problem with ext4, XFS, or another extent-based filesystem is inherent in their design, afaik. As far as I understand the described problem does not directly affect this patch as there is no "rename" done. Of course dropping the fsyncs for the indexes may lead to a corruption of the indexes and the db environment. But both can be recovered as described on http://www.rpm.org/wiki/Docs/RpmRecovery. Omitting the fsyncs can also just lead to additional damage if there is a power loss or any other hard disruption of the OS. So the risk is comparably limited if I didn't miss something else. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] RPMDB Performance
Hi! Very difficult to recover from a zero byte RPMDB Packages file, i think. Overall there is, as always, a tradeoff between performance and integrity. Even with this patch fsync is always called after writes to the Packages file (in opposite to adding "nofync" to the rpmdb configuration macro). So ending upwith an empty Packages file should really not happen. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] relicensing for Maximum RPM
On 08/31/2009 10:42 PM, Karsten Wade wrote: On Mon, Aug 31, 2009 at 10:58:09PM +0300, Ville Skyttä wrote: On Monday 31 August 2009, Karsten Wade wrote: I don't easily see where the source for the updated MaxRPM snapshot is; that would be helpful in gathering a list of all copyright holders. It used to be in a Mercurial repository at http://hg.rpm.org/max-rpm but that doesn't seem to exist any more (I still have an old working clone from there). I suppose it's http://rpm.org/gitweb?p=max-rpm.git nowadays. Is that just the names that appear in the snapshot? Paul, Matthias, and Ville? Based on git logs, jbj has worked on it quite a bit as well. IANAL and have no clue about the US copyright laws but I'd assume that the copyright is by RHT and not the authors. Florian -- Reg. Adresse: Red Hat GmbH, Hauptstätter Str. 58, 70178 Stuttgart Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [RFC][PATCH] Large file support
Hi!
I had a look at the 4GB per packaged file limit. The current cpio format
[1] uses 8 bytes to encode 32 bit integers as hexadecimal ASCII strings.
So there is no way of fixing this problem while staying compatible with
the cpio format (and keep rpm2cpio working).
Having a look at the tar formats I do not belief that switching to tar
is a real option. The format is just horrible (GNU tar needs over 200
lines to read an integer out of a header field) and full of hacks to
remain backward compatible (header in header + extentions). This would
be all not that bad if there where a nice little library we could link
against...
My favorite solution would be to use no payload format at all and just
rely on the meta data we ship in the header anyway. While this would
surely be possible it requires redoing the hard link handling (as hard
links are treated specially in the payload - like shipping the content
just once) and modifying the next upper layer within rpm (fsm.c) which
is probably the most horrible place in the whole code base. Volunteers
welcome!
A much simpler alternative would be to use a slightly modified cpio
format. With a new magic for large files we could just put an binary
integer into the c_filesize field (or all integer fields). Another
solution could be to keep the hexadecimal encoding and just double the
c_filesize or even some more integer fields.
This will both render the payload incompatible with cpio if there are
large files (and only then).
I did not yet ask cpio upstream or our cpio package maintainer about
accepting patches to at least read such archives...
Attached patch uses a binary integer for large file sizes. Patch is
untested and assumes that everything else that deals with file sizes
already is 64 bit save.
Comments? Ideas? Panic?
Florian
[1] http://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt (see
"New ASCII Format")
--
Reg. Adresse: Red Hat GmbH, Hauptstätter Str. 58, 70178 Stuttgart
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Charles Cachera
>From 4804fcca8a2ee33e60d8a7a042c01443e35b2ae9 Mon Sep 17 00:00:00 2001
From: Florian Festi
Date: Wed, 9 Sep 2009 12:06:54 +0200
Subject: [PATCH] Add support for 64 bit file sizes to cpio
---
lib/cpio.c | 27 +--
lib/cpio.h |3 ++-
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/lib/cpio.c b/lib/cpio.c
index 9003494..db6acbf 100644
--- a/lib/cpio.c
+++ b/lib/cpio.c
@@ -8,7 +8,7 @@
*/
#include "system.h"
-
+#include
#include
#include
@@ -87,15 +87,21 @@ int cpioHeaderWrite(FSM_t fsm, struct stat * st)
dev_t dev;
int rc = 0;
-memcpy(hdr->magic, CPIO_NEWC_MAGIC, sizeof(hdr->magic));
SET_NUM_FIELD(hdr->inode, st->st_ino, field);
SET_NUM_FIELD(hdr->mode, st->st_mode, field);
SET_NUM_FIELD(hdr->uid, st->st_uid, field);
SET_NUM_FIELD(hdr->gid, st->st_gid, field);
SET_NUM_FIELD(hdr->nlink, st->st_nlink, field);
SET_NUM_FIELD(hdr->mtime, st->st_mtime, field);
-SET_NUM_FIELD(hdr->filesize, st->st_size, field);
-
+if (st->st_size <= UINT64_MAX) {
+ SET_NUM_FIELD(hdr->filesize, st->st_size, field);
+ memcpy(hdr->magic, CPIO_NEWC_MAGIC, sizeof(hdr->magic));
+
+} else {
+ uint64_t fsize = htole64(st->st_size);
+ memcpy(hdr->filesize, &fsize, sizeof(fsize));
+ memcpy(hdr->magic, CPIO_LARGE_MAGIC, sizeof(hdr->magic));
+}
dev = major(st->st_dev); SET_NUM_FIELD(hdr->devMajor, dev, field);
dev = minor(st->st_dev); SET_NUM_FIELD(hdr->devMinor, dev, field);
dev = major(st->st_rdev); SET_NUM_FIELD(hdr->rdevMajor, dev, field);
@@ -122,6 +128,8 @@ int cpioHeaderRead(FSM_t fsm, struct stat * st)
char * end;
unsigned int major, minor;
int rc = 0;
+int small = strncmp(CPIO_LARGE_MAGIC, hdr.magic,
+ sizeof(CPIO_LARGE_MAGIC)-1);
fsm->wrlen = PHYS_HDR_SIZE;
rc = fsmNext(fsm, FSM_DREAD);
@@ -131,7 +139,8 @@ int cpioHeaderRead(FSM_t fsm, struct stat * st)
memcpy(&hdr, fsm->wrbuf, fsm->rdnb);
if (strncmp(CPIO_CRC_MAGIC, hdr.magic, sizeof(CPIO_CRC_MAGIC)-1) &&
- strncmp(CPIO_NEWC_MAGIC, hdr.magic, sizeof(CPIO_NEWC_MAGIC)-1))
+ strncmp(CPIO_NEWC_MAGIC, hdr.magic, sizeof(CPIO_NEWC_MAGIC)-1) &&
+ small)
return CPIOERR_BAD_MAGIC;
GET_NUM_FIELD(hdr.inode, st->st_ino);
@@ -140,7 +149,13 @@ int cpioHeaderRead(FSM_t fsm, struct stat * st)
GET_NUM_FIELD(hdr.gid, st->st_gid);
GET_NUM_FIELD(hdr.nlink, st->st_nlink);
GET_NUM_FIELD(hdr.mtime, st->st_mtime);
-GET_NUM_FIELD(hdr.filesize, st->st_size);
+if (small) {
+ G
Re: [Rpm-maint] [RFC][PATCH] Large file support
On 09/09/2009 08:32 PM, Ville Skyttä wrote: On Wednesday 09 September 2009, Florian Festi wrote: Having a look at the tar formats I do not belief that switching to tar is a real option. The format is just horrible (GNU tar needs over 200 lines to read an integer out of a header field) and full of hacks to remain backward compatible (header in header + extentions). This would be all not that bad if there where a nice little library we could link against... libtar doesn't qualify? http://www.feep.net/libtar/ Not that I know anything about it, but it might at least satisfy "little". It didn't look very trust worthy when visiting the page some days ago. Having a look at the ML archive now I am quite sure that it doesn't qualify. A library would need to be under active maintenance and have a chance to be still around in 5 or 10 years. GNU tar e.g. would, but they don't offer a library... Anyway, thanks for having a look. If there is a great library or archive format that should e considered feel free to bring it up. I just had a look at the XAR format (used by rpm5) but development also already has slowed down while some issues are still open (like creating the promissed DTD). It also has the disadvantage of pulling in a long tail of dependencies. In general I thing a format without an index and without internal compression (as cpio or tar) fits the RPM use case better than formats with an file index at the end or the beginning that use by file compression. As we typically package lots of small files I expect the compression rate to significantly drop when switching to by file compression. But I cannot back that up with real data right now. Florian -- Reg. Adresse: Red Hat GmbH, Hauptstätter Str. 58, 70178 Stuttgart Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [deltarpm] Setting inode # to 0 in delta rpms
Hi! I've been discussion various details about deltarpm weth Michael Schröder. He mentioned that the inode number is set to 0 when creating the delta and also when reconstructing the package because the files on disk do no longer carry the inode number that have been assigned to them in the cpio payload. After a couple of days this have come back to my mind. My first thought was: This should not be necessary as you can reconstruct the inode numbers from the old rpm header. My second thought was: True but this won't save anything as the inode numbers will be different between the packages anyway. Third thought: Would using artificially created inode numbers reduce the size of the deltas? May be increasing the inode number to the next 10 or 100 step to avoid changing all inode numbers when adding one file at the begining of the package? Don't know if this does make sense at all. But may be someone wants to pick it up... Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] %logfile option for filelists
On 12/01/2009 06:25 PM, Seth Vidal wrote: Now, that behavior of %ghost is correct for logfiles - but not always correct for other files. I was thinking if we had a %logfile option so those files did not get removed when the pkg was erased and treat %ghost files differently. Changing the behavior of an already existing tag is very unlikely to happen. You better come up with a new name for the behavior you want to give to the %ghost tag. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] wiki edit rights
On 01/10/2012 11:44 PM, David Greaves wrote: Hi Could I (username lbt) get wiki edit rights please David Done. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Improve macro table performance
On 01/28/2013 04:05 AM, Alexey Tourbin wrote: > In the existing implementation, when a new macro is added, the whole > table has to be sorted again. Hence the cost of adding n macros is > worse than O(n^2), due to arithmetic progression. > > This change drops all qsort(3) stuff altogether, by carefully preserving > table in sorted order. In findEntry routine, bsearch(3) is replaced > with customized binary search which tracks position for insertion. > In the addMacro routine, if a matching entry is not found, this > position is used for direct insertion, after the rest of the elements > are "shifted to the right" with memmove(3). Likewise, in delMacro > routine, the elements are shifted back to the left when the last macro > definition is popped. Technically, shifting half of the array with > memmove(3) is still O(n^2); however, modern CPUs process contiguous > memory in a very efficient manner, and glibc provides a fine-tuned > memmove(3) implementation. > > Also, macro table entries are now allocated in a single chunk. > > This change reduces rpm startup costs by factor of 6 (see callgrind > annotations below). Also, this change improves specfile parser > performance by a factor of 2 (e.g. the parse time of texlive.spec > is reduced from 67s to 35s). Impressive numbers. I wonder if thing could even improve further by switching to a hash table. RPM has it's own generic hash data type found in lib/rpmhash.H and lib/rpmhash.C These work with some kind of include magic. You #define HASHTYPE as a prefix used for the datatype and all related functions. HTKEYTYPE for the key data type and HTDATATYPE for value data type. This can also be a struct for keeping the value inside the hash. There can be more than one value per key. With HTDATATYPE undefined the hash acts as a set. After setting these macros the rpmhash.[HC] fiels are include to build the header or code for the given types. See lib/depends.c for two examples of how it is used. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Improve macro table performance
On 01/29/2013 10:05 PM, Alexey Tourbin wrote: > Meanwhile, > I argue that the change is worth applying anyway, because it removes > qsort(3) stuff and makes use the underlying data structure in a more > concise and explicit manner - such that it will be easier to try > another data structure. Yes, it is a huge step forward. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] newly registered user cannot submit new tickets to Trac
On 01/31/2013 01:49 PM, Adam Spiers wrote: > Is that an issue with the system? Kindof. We had to close the ticket system due to spam. I added you to the proper group. So creating tickets should work now. I will update the wiki page. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Rpm Database musings
On 03/01/2013 05:32 PM, Michael Schroeder wrote: > (the median is quite different from the avg, that means that > some packages are quite big.) ... > - That means, if I have 2000 packages installed on my system > (which is about the real number), the concatenated headers will > use 20 MByte (using the median), 10 MByte when using LZO > compression, 7.5 with xz. My guess is that the typically installed package are the bigger ones while a large number of rarely installed add-on packages are rather small (at least in header size). So it might be worth using one machine as an example instead of doing calculations with the "average package". Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Large file support
Hi!
Here is the first version of a patch set adding large file support to
RPM. It uses a own file format that is in the spirit of cpio but only
contains the file number and file size in the header - omitting all
other meta data. With a bit more thought may be even these two pieces of
data might be omitted.
Right now there is no way to switch between the two formats. Packages
with large files are generated with the new format.
The new format will fail rpm2cpio. In the long run we need a new tool
converting rpm packages into more modern archive formats.
Florian
>From d190860b62cd8303a89f2562ad0ab7328db5eb1e Mon Sep 17 00:00:00 2001
From: Florian Festi
Date: Fri, 19 Apr 2013 14:13:46 +0900
Subject: [PATCH 1/8] Load LONGFILESIZES into rpmfi if present
---
lib/rpmfi.c | 7 +--
lib/rpmfi_internal.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/rpmfi.c b/lib/rpmfi.c
index 6428fbf..db9bac6 100644
--- a/lib/rpmfi.c
+++ b/lib/rpmfi.c
@@ -246,6 +246,8 @@ rpm_loff_t rpmfiFSizeIndex(rpmfi fi, int ix)
if (fi != NULL && ix >= 0 && ix < fi->fc) {
if (fi->fsizes != NULL)
fsize = fi->fsizes[ix];
+else if (fi->lfsizes != NULL)
+fsize = fi->lfsizes[ix];
}
return fsize;
}
@@ -1152,9 +1154,10 @@ static int rpmfiPopulate(rpmfi fi, Header h, rpmfiFlags flags)
_hgfi(h, RPMTAG_FILEFLAGS, &td, scareFlags, fi->fflags);
if (!(flags & RPMFI_NOFILEVERIFYFLAGS))
_hgfi(h, RPMTAG_FILEVERIFYFLAGS, &td, scareFlags, fi->vflags);
-if (!(flags & RPMFI_NOFILESIZES))
+if (!(flags & RPMFI_NOFILESIZES)) {
_hgfi(h, RPMTAG_FILESIZES, &td, scareFlags, fi->fsizes);
-
+_hgfi(h, RPMTAG_LONGFILESIZES, &td, scareFlags, fi->lfsizes);
+}
if (!(flags & RPMFI_NOFILECOLORS))
_hgfi(h, RPMTAG_FILECOLORS, &td, scareFlags, fi->fcolors);
diff --git a/lib/rpmfi_internal.h b/lib/rpmfi_internal.h
index 19484ec..f82dbe7 100644
--- a/lib/rpmfi_internal.h
+++ b/lib/rpmfi_internal.h
@@ -26,6 +26,7 @@ struct rpmfi_s {
uint32_t * dil; /*!< Directory indice(s) (from header) */
rpm_flag_t * fflags; /*!< File flag(s) (from header) */
rpm_off_t * fsizes; /*!< File size(s) (from header) */
+rpm_loff_t * lfsizes; /*!< File size(s) (from header) */
rpm_time_t * fmtimes; /*!< File modification time(s) (from header) */
rpm_mode_t * fmodes; /*!< File mode(s) (from header) */
rpm_rdev_t * frdevs; /*!< File rdev(s) (from header) */
--
1.7.11.7
>From 85d90a519a5ae9edfd51c520a0a866148728f2f7 Mon Sep 17 00:00:00 2001
From: Florian Festi
Date: Fri, 19 Apr 2013 15:46:02 +0900
Subject: [PATCH 2/8] Add support for 64bit sizes to
rpmfi[SG]etFReplacedSizeIndex
---
lib/rpmfi.c | 26 +-
lib/rpmfi_internal.h | 1 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/lib/rpmfi.c b/lib/rpmfi.c
index db9bac6..3995b72 100644
--- a/lib/rpmfi.c
+++ b/lib/rpmfi.c
@@ -1076,6 +1076,7 @@ rpmfi rpmfiFree(rpmfi fi)
fi->fflags = _free(fi->fflags);
fi->vflags = _free(fi->vflags);
fi->fsizes = _free(fi->fsizes);
+ fi->lfsizes = _free(fi->lfsizes);
fi->frdevs = _free(fi->frdevs);
fi->finodes = _free(fi->finodes);
@@ -1092,6 +1093,7 @@ rpmfi rpmfiFree(rpmfi fi)
fi->apath = _free(fi->apath);
fi->replacedSizes = _free(fi->replacedSizes);
+fi->replacedLSizes = _free(fi->replacedLSizes);
fi->h = headerFree(fi->h);
@@ -1291,11 +1293,23 @@ rpmfi rpmfiNew(const rpmts ts, Header h, rpmTagVal tagN, rpmfiFlags flags)
void rpmfiSetFReplacedSizeIndex(rpmfi fi, int ix, rpm_loff_t newsize)
{
if (fi != NULL && ix >= 0 && ix < fi->fc) {
- if (fi->replacedSizes == NULL) {
- fi->replacedSizes = xcalloc(fi->fc, sizeof(*fi->replacedSizes));
+/* Switch over to 64 bit variant */
+if (newsize>UINT32_MAX && fi->replacedLSizes == NULL) {
+fi->replacedLSizes = xcalloc(fi->fc, sizeof(*fi->replacedLSizes));
+/* copy 32 bit data */
+if (fi->replacedSizes) {
+for (int i=0; ifc; i++)
+fi->replacedLSizes[i] = fi->replacedSizes[i];
+fi->replacedSizes = _free(fi->replacedSizes);
+}
+}
+if (fi->replacedLSizes != NULL) {
+fi->replacedLSizes[ix] = newsize;
+} else {
+if (fi->replacedSizes == NULL)
+fi->replacedSizes = xcalloc(fi->fc, sizeof(*fi->replacedSizes));
+fi->replacedSizes[ix] = (rpm_off_t) newsize;
}
- /* XXX watch out, replacedSizes is not rpm_loff_t (yet) */
- fi->replacedSizes[ix] = (rpm_off_t) newsize;
}
}
@@ -1305,7 +1319,9 @@ rpm_loff_t rpmfiFReplacedSizeIndex(rpmfi fi, int ix)
Re: [Rpm-maint] RPM tag not working
On 10/14/2013 09:49 AM, prashant tyagi wrote: > Hi, > > I have rpm documentation for renaming the package. I get to know about > tag. I am able to build a new package successfully after > adding this tag in spec file. For example: > > Suppose there is a package PkgA , I want to rename it to PkgB... > For PkgB- > Obsoletes: PkgA <= 2.00.000-1 > > But When I install PkgB, it is not uninstalling PkgA. Instead PkgA and > PkgB are installed side by side. You have to "install" package B with "rpm -U pkgB". U for update. Updaters like yum do the right thing. For historical reasons rpm -i does not take obsoletes into account as it is supposed to leave other packages alone. Florian PS: In general such questions are better suited for the rpm user list rpm-l...@lists.rpm.org as it has a wider audience which gives a better chance for quick responses. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RPM tag not working
On 10/15/2013 01:13 PM, prashant tyagi wrote: > Hi Panu, > > Thanks for quick reply. > It worked with 'rpm -U'. I have got another problem in tag. > > Hi All, > > Here is the complete scenario: > > I have two packages pkgA 10.10.100, pkgB 10.10.100 and I want to merge > these into pkgC 20.00.000. > The thing I want to achieve If I install pkgC, it should remove pkgA > and pkgB. and if I try to install pkgA or pkgB higher version, it > should tell me "already higher version is installed'. > what I did to achieve this- > I used and tags in spec file for pkgC like this : > > Obsoletes: pkgA <= 10.10.100-1, pkgB <= 10.10.100 > Provides: pkgA <=20.00.000-1, pkgB <20.00.000-1 > > when I use- rpm -U pkgC, it remove pkgA and pkgB ( > working), but I install pkgA higher version (10.20.200),it got > installed ( not working ). > Is there any other way to achieve this? In general the way of solving this is not issuing a higher version of pkgA and pkgB. In cases you do not control those packages you can add a Conflict: pkgA and Conflict: pkgB to pkgC which issues an error if those packages are being installed while pkgC is on the system. Adding such Conflict:s without a version number is a bit fishy but this is needed here to rule out all future versions that might come out during pkgC's life time. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Idea of the day
Hi! While discussing updates and version-in-package-names issues (related to a programming language that shall not be named) we came up with the following (completely not thought through) idea: Offer a special character for separating the version number within the package name from the "real" name e.g. "@". While updates would continue to work as they do right now and foo@1-1.2.3 is only do be updated by other foo@1 versions the "@" has the following effects: Whenever you query for or address a package (name) you also match the part before the @. So you could do rpm -e foo-1.2.3 which would remove foo@1-1.2.3 Whenever the name or NVR is printed in the UI the part after the @ is omitted and the matching part of the number is highlighted if possible: foo-*1*.2.3 May be even automatically add a Provide for the part before the @. Benefit of the idea: All "real" operation just keep working as they used to. We have the wanted behaviour on the UI of not showing the version number twice and matching the name without the version number. This feature could also be used for library packages. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Heads up: Weak and rich dependencies in RPM
Hi! We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: #1 Adding weak dependencies as already used by SuSE and others: Recommends:, Suggests:, Supplements: and Enhances:. We agreed with Michael Schröder to not use SuSE's current implementation but to add new tags for a cleaner interface and an easy update path for already existing packages. This is planned to be part of the next RPM version. As old tools will just ignore the new tags this isn't a big compatibility issue. Support in rpmbuild can probably back ported easily. #2 Allow Boolean expressions of (Name Flag Version) terms in Requires:, Conflicts: and the new weak dependencies (rich dependencies). This will add a new expressive strength to RPM's dependency model and allow fixing a couple of packaging problems we don't have a solution for right now and also get rid of some special case solutions like hand coded language pack support. As we are still figuring out some of the implementation details and implications this feature may or may not make it in the next release. Packages using such Boolean expressions will not work with old versions of rpm and other related tools and it is still unclear to what extend this feature can be back ported. What implication does this have on your distribution? Although this new features do affect rpm and packages directly and you may want to reflect that in your packaging policy the main impact is outside of rpm itself. The weak dependencies are basically ignored by rpm and need to be handled in your dependency solver, installer, updater, software management tool - however you call it. If you are already using weak dependencies you want to make sure to add support for the new tags before updating to the next major rpm version. Also expect that most of your patches adding the old support will fail to apply. In general I expect the transition to be comparably easy. We will probably even add some compatibility code in upstream RPM to make your life easier. Talk to us. Getting the support into createrepo and libsolv is taken care of. This should cover Fedora and OpenSUSE and may be others. If you use a different dependency solver you have various options: You may just ignore the new features for now. The weak dependencies can just be ignored. But you won't be able to process packages with Boolean expression in Requires: or Conflicts:. If your solver is not NP complete you may want to consider changing to a libsolv based solution or any other NP complete solver that has a chance of growing support for weak and rich dependencies in the future. If you already have a NP complete solver - may be already with support for weak dependencies - and want to stick with it you should consider adding support for rich dependencies. Right now there is no code to look at and there are still some implementation details that we need to figure out. We will keep you updated on the rpm-maint list. I wrote a document describing more technical details. Find it attached to this mail. Florian rich_relations.odt Description: application/vnd.oasis.opendocument.text ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Weak dependencies SUSE compatibility patch
On 02/25/2014 03:25 PM, Michael Schroeder wrote: > attached is a little patch that I have in my rpm to make --recommends > et al work with old SUSE rpms. Thanks! Applied. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Weak dependencies SUSE compatibility patch
On 03/11/2014 04:07 PM, Michael Schroeder wrote: > I also need the following patch to make rpm export the old tags. Pushed with a little tweaking. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Upgrade requirements
On 04/17/2014 09:05 AM, Shapiro Ben wrote: > Hi all. > I've been looking around and trying for some time to create the > following situation: > I have an application v3.0 packaged and i have to update lots of clients > which some have v2.0 installed, some have v1.0. there is major changes > between the baselines so i want to require from those who have v1.0 > installed, to automatically download and install v2.0 first and just > then v3.0 > When i use the Required section "Required: app >= 2.0" it still does not > work. it installs v3.0 over 1.0 without requiring v2.0... Is it possible > to achieve?? No. RPM does always update to the newest version. The right way to solve this is to ship the scripts that can update from all versions to the current one within the newest (and there fore all) package(s). Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] read rpm database with Java
In other words: If you do not need a lot of data try getting along with CLI and --qf and save yourself a lot of trouble. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RPM 4.12.0 alpha released
On 06/29/2014 01:51 PM, Florian Weimer wrote: > On 06/27/2014 04:41 PM, Panu Matilainen wrote: > >> - Support for files over 4GB in packages > > Is the new payload format documented somewhere? It seems to use the FX > index in a pseudo-cpio header instead of duplicating the data from the > header, but it would be nice to to see this spelled out explicitly. Not yet. It should probably be added to the rpm.org page describing the file format. Be aware that we have not yet decided on making the new format part of the API. Note also that we added an API for accessing the payload data. Have a look at the rpm2archive(.c) utility to get an idea how it works. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Please allow ovitters to report bugs
On 07/29/2014 01:01 AM, Olav Vitters wrote: > As per subject. > > This is a pretty cumbersome process btw. Yes. Yes, it is Done. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RFC: experiments with rich dependencies
On 09/11/2014 02:18 PM, Panu Matilainen wrote: > [*] IF-dependencies have similar issues as reverse dependencies: one can > break somebody elses dependencies by installing some seemingly unrelated > package. Perhaps they should be limited to weak dependencies. That's not exactly the same situation. Reverse Requires can make your installation "broken" by adding a package to the repository. While I agree tha most use case should and will probably use weak dependencies I do not see anything intrinsicly wrong about forcing in an intermediate package (or act as a conflict in case this package is not available) Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RFC: experiments with rich dependencies
On 09/11/2014 02:51 PM, Michael Schroeder wrote: > Ah, but I was hoping for a discussion of the syntax. Are you ok with > the enclosing the rich deps with ()? What about the op names, I'd > love to use & as 'and' and | as 'or' (which also makes it more like > Debian), but I can't think of any good charater for 'if'. Formally the sign would be "<-" (reverse implication). But I kinda doubt that most people would get that. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] How to get RPM requires quickly
On 09/15/2014 02:42 PM, Panu Matilainen wrote: > On 09/13/2014 04:13 PM, Richard W.M. Jones wrote: >> >> We have a program[1] that needs to take a list of installed RPM >> package names, and quickly generate all of the installed dependencies >> (recursively). > To get rpm do a bit more work for you, use 'rpm -e --test' to make rpm > resolve the deps. Basically I don't think these are same things. 'rpm -e' gives the packages requiring the package in question while I think the original question was for the packages required *by* the package. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [RFC v4 06/11] Add rpmtags for file signatures and their length
On 01/13/2015 07:33 PM, f...@linux.vnet.ibm.com wrote: > This patch adds rpmtags for file signatures and their length, so they can be > stored in the package header. This patch needs to go before [RFC v4 04/11] Add support for file signatures to rpmfi and rpmfiles as the tags are used there. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [RFC v4 04/11] Add support for file signatures to rpmfi and rpmfiles
On 01/13/2015 07:33 PM, f...@linux.vnet.ibm.com wrote: Ok, some minor knitpicks: > This patch adds file signatures and file signature length to rpmfiles. These > new members are set in rpmfilesPopulate, and they can be accessed with > rpmfiFSignature. > > Signed-off-by: Fionnuala Gunter > +char *rpmfiFSignatureHex(rpmfi fi) Missing whitespace after "*". > if (!(flags & RPMFI_NOFILERDEVS)) > + > _hgfi(h, RPMTAG_FILERDEVS, &td, scareFlags, fi->frdevs); Errous empty line. > +/** \ingroup rpmfi > + * Return current file (hex) signature of file info set iterator. > + * The file info set iterator stores files signatures in binary format to > + * conserve memory, this converts the binary data back to hex presentation > used > + * in headers. > + */ > +char * rpmfiFSignatureHex(rpmfi fi); char * rpmfilesFSignatureHex(rpmfi fi); missing (ok, can be argued if really needed) > +RPMFI_NOFILESIGNATURES = (1 << 18), Not actually used. Should probably guard the new code in rpmfilesPopulate() Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Identifying which files need signatures
On 01/16/2015 11:18 PM, Fionnuala Gunter wrote: > Hi, > > Missing from the RPM patches that add file signatures is a way for > package maintainers to specify which files need signing. Dmitry > Kasatkin suggested that we enumerate signed files with a spec tag, > similar to how we enumerate files, ie. I wonder if there is a way around all this. Right now we already have the files divided up into normal files which are supposed to not change and config files which are expected to change. I wonder if this distinction is already sufficient. Also note that prelink will happily alter binary files. The verify code in rpm undoes the prelinking for checking digests of binary files. I wonder if this can be done with the signatures, too. Otherwise prelink needs to be disabled for the whole signing to work (as I guess binaries are a primary target for signing) Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Read uncompressed patches from stdin
Thank you very much for spotting and doing the research. Pushed to master. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Use setexecfilecon() from libselinux instead of ad-hoc code
On 01/15/2015 05:01 PM, Guillem Jover wrote: > This function was factored out from rpm_execcon() upstream to make it > easier to use by its users, by making it not call execve() directly. It > is now also used by dpkg since 1.17.11. > > Preserve the ad-hoc code for now so that it can be compiled against old > libselinux versions. Thanks for the patch! Pushed. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Add API to completely disable librpm's use of Unix signal handlers
Sorry, for the last response. DevConf takes its toll... On 01/23/2015 04:07 AM, Colin Walters wrote: > Numerous consumers of librpm use it in a pattern where they're > constructing fresh chroots. For example, rpm-ostree operates this > way, and is used to provide atomic upgrades in concert with rpm. > > If the process dies due to SIGINT or another signal, the root can > simply be discarded. > > Currently today, rpm-ostree undoes the signal handlers after loading > librpm so that Control-C does what I want, but there's still a race > condition where the interrupt can be lost. > > Add an API so callers can disable the behavior. Is there any chance someone would want to switch them back on? My gut feeling tells me this should rather be rpmsqSetInterruptSafety(int on); Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] RPM repository moved to GitHub
Hi! We moved your Git repository to GitHub[1] into the rpm-software-management project[2] where a lot of other rpm related repositories already reside. The original repository[3] will stay in place is updated from the GitHub one. If you have a local checkout you can continue to use is read only. If you have write access to the repository please move over the the GitHub repository and request access there. To switch over your local checkout to the new repository use one of the following commands: git remote set-url origin https://github.com/rpm-software-management/rpm.git git remote set-url origin g...@github.com:rpm-software-management/rpm.git Thanks! Florian [1] https://github.com/rpm-software-management/rpm [2] https://github.com/rpm-software-management [3] http://rpm.org/git/rpm.git/ -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] MT compression in rpmbuild ?
On 03/26/2015 12:42 PM, Håkan Olsson wrote: > Hello, > > I’m looking for various ways forward in speeding up RPM build times. In our > various build pipelines (Continuous Integration, …) a common resource usage > scenario is nice parallel compilations (-j10 or up, etc), after which the > build spends several minutes in rpmbuild, with just one core running at 100%. > Developers are in various ways skipping the RPM generation step in many cases > due to this, not really what we want. Welcome to the list! > The little investigation I’ve done points to not very many (or any?) > compression libraries themselves capable of multi-threading, what’s available > seems to be mostly/only applications such as pxz, pbzip2, pigz using the > standard libraries. With rpmbuild using a library rather than e.g. streaming > output to a child process replacing this appears to require a coding effort. My guess is that choosing the right tools/libraries is one of the more difficult parts. It might be possible to just do compression in a separate process for some formats, though. The compression handling code is actually one of the less ugly corners. It can be found in rpmio/rpmio.c [1]. It implements an abstract file descriptor data type. The patches adding lzma support[2] give a rough idea of what is needed to add a new compression format (although some things have changed since then. E.g. the name of the format changed to xz). > I have a support case with RedHat open into investigating ways forward and > one of the suggestions was to ask here. Possibly this has been discussed > before? I got some question forwarded. So if you got some answers from "Engineering" they are probably from me. > (e.g. “deltarpm” has been mentioned as an issue, but at least in my case this > is not a concern - we won’t be using it.) Well, it is one reason for requiring bit for bit reproducibility of the compression stage. But having bit for bit reproducibility is an value on its own. So this is something to test for when choosing the library/tool. Florian [1] https://github.com/rpm-software-management/rpm/blob/master/rpmio/rpmio.c [2]341266ae26e6685d1d870b28533469c653355bb7.. edc5c0ef84a93d19acecaaf9a07f4ea3e9d8fe39 -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] New Rpm-ecosystem Mailing List
Hi! tl;td: Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem if your interested in any part of the rpm ecosystem. While there are quite some mailing lists already that deal with the different tools around and including rpm we realized that there is no good place to discuss issues that involve multiple parts of (our own) package handling stack even less so to stay in contact with other rpm based solutions. To solve this we create a new mailing list: rpm-ecosys...@lists.rpm.org Normal user questions and development talk is supposed to stay on the per project mailing lists. The new list is for questions like: * How do other implementations handle specific problems? * Is this new feature interesting for downstream distributions? * How do the different packaging guidelines treat a special topic? * Anyone there to support our demand for this new rpm feature? And it is for topics like: * Packaging guide lines * RPM features * Build systems and compose tools * Dependency solvers, installers and updaters * RPM based image creation / non rpm based updates for rpm based distributions In short: It is meant to bind the rpm universe together. Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem Please forward this mail to anyone that might be interested - especially to rpm related sub projects and groups. Thanks! Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] New Rpm-ecosystem Mailing List
> Please forward this mail to anyone that might be interested - especially > to rpm related sub projects and groups. Can someone forward this mail to the Mageia folks, please? I signed up to a few MLs to get the message out but I won't start creating account for other distros. Thanks! Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH v7 03/11] Add rpmtags for file signatures and their length
On 07/21/2015 12:11 AM, Fionnuala Gunter wrote:
> From: "f...@linux.vnet.ibm.com"
>
> This patch adds rpmtags for file signatures and their length, so they
> can be stored in the package header.
>
> Changelog:
> - update rpmtag values (rebase error) - Mimi
> ---
> lib/rpmtag.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/rpmtag.h b/lib/rpmtag.h
> index 6c7dbf2..d06a3b7 100644
> --- a/lib/rpmtag.h
> +++ b/lib/rpmtag.h
> @@ -350,6 +350,8 @@ typedef enum rpmTag_e {
> RPMTAG_TRANSFILETRIGGERVERSION = 5081, /* s[] */
> RPMTAG_TRANSFILETRIGGERFLAGS = 5082, /* i[] */
> RPMTAG_REMOVEPATHPOSTFIXES = 5083, /* s internal */
> +RPMTAG_FILESIGNATURES= 5084, /* s[] */
> +RPMTAG_FILESIGNATURELENGTH = 5085, /* i */
>
> RPMTAG_FIRSTFREE_TAG /*!< internal */
> } rpmTag;
>
This break test case 004. This should fix it:
diff --git a/tests/rpmgeneral.at b/tests/rpmgeneral.at
index 61cc2fb..332adf6 100644
--- a/tests/rpmgeneral.at
+++ b/tests/rpmgeneral.at
@@ -113,6 +113,8 @@ FILENLINKS
FILEPROVIDE
FILERDEVS
FILEREQUIRE
+FILESIGNATURELENGTH
+FILESIGNATURES
FILESIZES
FILESTATES
FILETRIGGERFLAGS
--
Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH v7 03/11] Add rpmtags for file signatures and their length
On 07/22/2015 04:30 PM, Fionnuala Gunter wrote:
> Florian,
>
> I'm going to send an updated patch 9. Should I also include this patch
> to fix test 004, when I resend the patch set?
>
> -Fin
>
> On Tue, Jul 21, 2015 at 5:53 AM Florian Festi <mailto:ffe...@redhat.com>> wrote:
>
> On 07/21/2015 12:11 AM, Fionnuala Gunter wrote:
> > From: "f...@linux.vnet.ibm.com <mailto:f...@linux.vnet.ibm.com>"
> mailto:f...@linux.vnet.ibm.com>>
> >
> > This patch adds rpmtags for file signatures and their length, so they
> > can be stored in the package header.
> >
> > Changelog:
> > - update rpmtag values (rebase error) - Mimi
> > ---
> > lib/rpmtag.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/rpmtag.h b/lib/rpmtag.h
> > index 6c7dbf2..d06a3b7 100644
> > --- a/lib/rpmtag.h
> > +++ b/lib/rpmtag.h
> > @@ -350,6 +350,8 @@ typedef enum rpmTag_e {
> > RPMTAG_TRANSFILETRIGGERVERSION = 5081, /* s[] */
> > RPMTAG_TRANSFILETRIGGERFLAGS = 5082, /* i[] */
> > RPMTAG_REMOVEPATHPOSTFIXES = 5083, /* s internal */
> > +RPMTAG_FILESIGNATURES= 5084, /* s[] */
> > +RPMTAG_FILESIGNATURELENGTH = 5085, /* i */
> >
> > RPMTAG_FIRSTFREE_TAG /*!< internal */
> > } rpmTag;
> >
Yes, please. Just squash it into [PATCH 03/11]
Florian
--
Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] RPM 4.13.0-alpha released
Time to wrap things up and stabilize all that changes to a new release. There are two big new features that we hope to get feedback on: * Boolean (aka "Rich") Dependencies * File triggers Beside that there are many other fixes, improvements and cleanups. For download information and further details, see the draft release notes: http://rpm.org/wiki/Releases/4.13.0 On behalf of the rpm-team, Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] really default to default XZ compression level
On 08/28/2015 02:46 PM, Thierry Vignaud wrote: > Hi > > This patches makes rpm really default to default XZ compression level > > BTW this fixes the default compression level which is 6 instead of 7. Added this one and the above upstream. Thanks for the patches. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [Patch] Fix file signature bugs
On 08/31/2015 11:39 PM, Fionnuala Gunter wrote: > Hi, > > The first patch fixes a bug that occurs when the signature header > changes sizes (after including file signatures). I revised it based on > Lubos' comments. The second patch fixes another bug where only the first > file signature was installed. Please pull if these fixes are acceptable. They look good. Pushed. Thanks! Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] RPM 4.13.0-rc1 released
Time to get 4.13.0 out. Here is the first release candidate.
There have been quite a few changes since the alpha. The most notable are:
* Added support for file signatures in security.ima xattr
* Finalized syntax for rich dependencies
* Enable {} expansion in rpmGlob()/%files and enhanced glob handling
But there are also smaller changes and fixes:
* Fix compressed patches
* Don't warn when an escaped macro is in comment.
* Add --filetriggers query option
* Fix for Py3 compatibility
* Do not bytecompile python scripts in docdir
* Improvements to find-lang.sh and perl dependency generator
* Use default value (currently 7) for XZ compression
if not value is given
For download information and further details, see the draft release
notes: http://rpm.org/wiki/Releases/4.13.0
On behalf of the rpm-team,
Florian
--
Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RPM 4.13.0-rc1 released
On 09/02/2015 03:25 PM, Florian Festi wrote: > Time to get 4.13.0 out. Here is the first release candidate. > > There have been quite a few changes since the alpha. The most notable are: > * Finalized syntax for rich dependencies Looks like I messed this one up. Current HEAD is already fixed. See https://github.com/rpm-software-management/rpm/commit/d20b7d2b00e349610f3cf08d9ff3723cc7c56e32 if you are interested in the details. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Add support for 'patch -o outfile'. (#18)
Closed #18. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/18#event-462274352___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] brp-python-hardlink: Handle Python 3.5's *.opt-[12].pyc (#16)
Pushed as is. Feel free to file new pull requests for the proposed improvements (We promise to review them faster than this one). --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/16#issuecomment-156096649___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Fix broken -q on %setup. (#20)
Closed #20. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/20#event-462296518___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Some minor localization fixes (#24)
Thanks for taking care. Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/24#issuecomment-156063054___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Add RubyGems support. (#27)
Closed #27. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/27#event-462253355___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Fix comment for doPatchMacro. (#19)
Thanks for the patch! Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/19#issuecomment-156068222___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Add RubyGems support. (#27)
Pushed to master. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/27#issuecomment-156053073___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Fix comment for doPatchMacro. (#19)
Closed #19. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/19#event-462300128___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Fix broken -q on %setup. (#20)
Thanks for the fix! Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/20#issuecomment-156067274___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Improvements to brp-compress & find-lang.sh (#12)
Closed #12. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/12#event-462411000___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Various fixes for new pythonegg dependency generator (#23)
Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/23#issuecomment-156154873___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Some minor localization fixes (#24)
Closed #24. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/24#event-462284346___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Add support for 'patch -o outfile'. (#18)
Pushed as squashed patch to master. Thanks for the patch! --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/18#issuecomment-156059100___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Various fixes for new pythonegg dependency generator (#23)
Closed #23. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/23#event-462619697___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] brp-python-hardlink: Handle Python 3.5's *.opt-[12].pyc (#16)
Closed #16. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/16#event-462402751___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Set up more portable definitions for alternative libc (μClibc and MUSL) (#26)
Thanks for the patch. Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/26#issuecomment-156110294___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Set up more portable definitions for alternative libc (μClibc and MUSL) (#26)
Closed #26. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/26#event-462457432___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Improvements to brp-compress & find-lang.sh (#12)
Closing this for now. Feel free to file a new PR if the issues of the remaining patch is resolved. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/12#issuecomment-156098775___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] brp-python-hardlink: Use cmp instead of sha1summing (#30)
Closed #30. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/30#event-468985726___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] brp-python-hardlink: Use cmp instead of sha1summing (#30)
Thanks for the patch! Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/30#issuecomment-158012044___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] pythoneggs.py: flake8 fixes (#31)
Closed #31. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/31#event-468988703___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] pythoneggs.py: flake8 fixes (#31)
Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/31#issuecomment-158013259___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Xz support improvements (#11)
Closed #11. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/11#event-469206927___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Xz support improvements (#11)
Obsolete now. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/11#issuecomment-158070494___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Improvements for xz support (#17)
Ok, pushed all but the very last patch to master. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/17#issuecomment-158071032___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] initial embedded python interpreter support (@rpm5.org derived) (#25)
On 11/19/2015 04:09 PM, Vít Ondruch wrote: > What is the usecase for this? Isn't this just feature bloat? I kinda agree that this looks like feature bloat. This patch set needs a very good justification to go in upstream. The overall trend is to rather keep minimal installs smaller as this is a big issue for containers and VMs. Python is one of the candidates to be thrown out at some point. Also embedding a particular version of Python into rpm itself makes this Python version part of the spec syntax with all kind of possibly ugly implications. It also seems to not bring many benefits except from saving the interpreter starting time (which can be significant if there are many Python scriptlets). But the trend here is also to rather getting rid of more of the scriptlets using the new file trigger feature (We'll see how this works out). Having access to the transaction objects of the running rpm instance could give such justification as it can hardly done in any other way. But I really, really doubt that we wan to go down that route. Especially as it gives a whole new way of how scriptlets can break a transaction. As the patch set is not interfering with many places in the rpm code it should be not too hard to maintain the changes outside of the upstream repository for distributions with (still) rely on this feature. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Fix %setup logic in presence of '-[cbaT]' options. (#21)
Thanks for looking that deeply into this! We opted for the second option. Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/21#issuecomment-159885205___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Fix %setup logic in presence of '-[cbaT]' options. (#21)
Closed #21. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/21#event-475481848___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Put all Perl-related macros in a single file. (#37)
Not sure if those macro can just be hidden away. We'd need to check how much packages this is going to break before doing such a change. It might be necessary to go the opposite direction (including the macros.perl unconditionally) and leave removing it again to the distros. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/37#issuecomment-176153756___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Unknown tag %ifdef. (#39)
Thanks for spotting this! --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/39#issuecomment-176156624___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Unknown tag %ifdef. (#39)
Closed #39. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/39#event-529599270___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Add lua function posix.close (#44)
This pull request is not sufficient to fix the problem. For one there is no
io.open in rpm's lua so far. Also we probably do not want random scriptlets to
mess with with the file descriptors of the rpm process. So this would need some
kind of protection (as we already added to exec and exit).
It might need to be a bit more complex, though, as permitting file operations
only after forking is kinda strange.
Also your proposed script relies on io.open("/dev/null") returning 2 as it
assumes that this is the lowest free file descriptor. This is really ugly and
probably unreliable. A proper solution would be to use dup2 (also not
available).
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/44#issuecomment-176179051___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Doc (#48)
Sorry, but the translations are done at https://www.transifex.com/rpm-team/rpm/ Changes to the translation files will just be overwritten. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/48#issuecomment-176184096___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Doc (#48)
Closed #48. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/48#event-529695803___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Doc (#48)
Ok, added all the doc updates. Changed the commit message for the GROUPS patch. I close this although the translation updates were dropped. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/48#issuecomment-176191782___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Add RPMCALLBACK_ELEM_PROGRESS callback type (#36)
Pushed. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/36#issuecomment-176251217___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] Add RPMCALLBACK_ELEM_PROGRESS callback type (#36)
Closed #36. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/36#event-529895073___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
