On Fri, 2011-09-16 at 12:02 +0300, Panu Matilainen wrote:
On 09/15/2011 01:55 PM, Jon Masters wrote:
1) Location of libraries and the like: the libraries for different ABI's
need to go to separate paths. Currently the non-debian world knows /lib
and /lib64, and while it's of course possible
On Mon, 2010-11-29 at 18:11 +0100, Michael Schroeder wrote:
On Fri, Nov 26, 2010 at 08:23:40PM +0100, Michael Schroeder wrote:
Having said that, the current behaviour seems to be quite broken.
Please explain the following:
Provides: foo 1.2-1
Requires: foo = 1.2 no match
On Mon, 2010-11-29 at 19:26 +0100, Michael Schroeder wrote:
On Mon, Nov 29, 2010 at 01:10:25PM -0500, James Antill wrote:
I'm not sure what you mean by explain ... I assume you know why it's
doing what it's doing, so I guess you are saying explain why we would
want it to do
On Mon, 2010-08-09 at 18:43 +0300, Anssi Hannula wrote:
Hi all!
Currently [1], if a package has
Provides: foo = 1.2
And another package has
Conflicts: foo 1.2-1
The conflict does not trigger, as the releases will be ignored if one of the
compared EVRs does not have it. (mdv bug #55810
On Wed, 2010-06-16 at 00:30 -0700, JD wrote:
Greetings all,
Is there a way to query the database to list the packages
that depend on a given package?
I checked the man page, and I do not see such an option.
I see the option --requires, which is great - but would like the
converse of
On Mon, 2010-05-03 at 15:10 +0300, Panu Matilainen wrote:
Um, what's wrong with just using rpm.version symbol which is already
exported to python in HEAD?
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=21962ab6142cd1e54f1087a545244de506d9abf1
Bah, because it's not in F-13 and I'm blind and
On Wed, 2010-04-14 at 13:30 -0400, Steve Lawrence wrote:
On Fri, 2010-04-09 at 10:40 -0400, James Antill wrote:
On Thu, 2010-04-01 at 16:45 -0400, Steve Lawrence wrote:
snip
It seems like you are in favor of bundling all policy into a single
policy package, adding that as a requirement
On Fri, 2010-02-12 at 15:31 -0500, Steve Lawrence wrote:
On Fri, 2010-02-12 at 15:20 -0500, Steve Lawrence wrote:
On Fri, 2010-02-05 at 12:26 -0500, James Antill wrote:
On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
+ case 0
On Fri, 2010-02-12 at 15:23 -0500, Steve Lawrence wrote:
If you are going to use rpm headers, use them and make them go away on
package removal
We can't remove the pseudo packages on package removal.
Well, you can ... but you don't want to :). Personally I find it hard
to believe anyone
On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
+ const char * rootDir = rpmtsRootDir(ts);
+ int dochroot = (rootDir != NULL !rstreq(rootDir, /) *rootDir
== '/');
+ if (dochroot) {
Wouldn't this be better as:
int dochroot = (rootDir != NULL rootDir[0] == '/'
On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
+ case 0:
+ if (!rpmIsDebug()) {
+ freopen(/dev/null, r, stdin);
+ freopen(/dev/null, w, stdout);
+
them and make them go away on
package removal ... if you want packages specific for policy, create
those at build time (and maybe use requires to help them not go away).
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.26
http
).
And the above looks like if %policy pkg1 was in pkgA and %policy
pkg2 was in pkgB this code will start doing really weird things (even
on downgrades! Because the uninstalled policy will be newer).
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org
On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
The state of SELinux on a system changes how we install policy during
the rpm transaction. For example, if the /etc/selinux directory structure
hasn't been created, we can't install policy until a package creates the
directory. This
On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
+ if (rstreq(headerGetString(h, RPMTAG_NAME), RPMPOL_PKG_NAME))
{
+ pol-source = headerGetAsString(h, RPMTAG_SOURCERPM);
+ } else {
+ pol-source = headerGetAsString(h, RPMTAG_NAME);
+ }
* set an epoch (if only for distro statistics
collection or whatever).
That's true, but does it really matter? What use are those stats?
I guess approaching it from the other point of view, what do you think
about changing rpmbuild to always store '0' in epoch?
--
James Antill - ja
. remove pkgX
2. install pkgY
...you have a whole new list of problems, if the transaction dies after
1 but before 2, and also for whatever is running between #1 and #2.
--
James Antill ja...@fedoraproject.org
Fedora
___
Rpm-maint mailing list
Rpm
this by doing a
chroot(.)
call.
This is usually done by keeping around an fd for the old ., and then
doing fchdir() on it (followed by chroot(.)).
--
James Antill ja...@fedoraproject.org
Fedora
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http
On Thu, 2009-10-15 at 15:15 -0400, David Malcolm wrote:
Preserve the string-based API to headers:
h['name']
by expecting a PyUnicode on Python 3, and a PyString on Python 2.
---
python/header-py.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git
... see init_rpm() and search
for TAG.
--
James Antill [EMAIL PROTECTED]
Red Hat
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
love that...
While that's true and it might be nice for rpm to call out to something
when it installed a package, I'm pretty sure you don't want config.
rollback inside rpm.
--
James Antill [EMAIL PROTECTED]
Fedora
___
Rpm-maint mailing list
Rpm-maint
of anything else that's
running on the system at the same time.
Which basically makes it worthless, IMO.
--
James Antill [EMAIL PROTECTED]
Red Hat
signature.asc
Description: This is a digitally signed message part
___
Rpm-maint mailing list
Rpm-maint
22 matches
Mail list logo
