Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
Per Øyvind Karlsen wrote: Why not just do 'rc = vercmppart(d1, d2);' when already parsing distepoch and passing it as a new argument to the functions? That's pretty much all that's needed for supporting distepoch in version comparision.. :) smart will still have an issue with composing the package name in ie. smart/backends/rpm/base.py: search() etc. due to the extra '-' in the name though.. Never mind , issue for me to fix with synthesis, been a while since I last looked at smart code.. You should still get this upstream, rather than hacking it in to your own downstream branch... Which means it will need some test cases, or at least real examples of what is being changed ? Yes, one could do EVRD comparisons instead. It's not all that different from when D was included in the R field. But what about splitrelease ? And it should all be integrated with smart trunk. --anders __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
d'oh, sent with wrong email address.. 2011/1/27 Per Øyvind Karlsen peroyv...@mandriva.org: 2011/1/27 Jeff Johnson n3...@mac.com: There's a deep political rift aka labelCompare() involving missing values that needs to be sorted through here. The same political rift affects your fix with missing values (my comment was something arch like You changed too many lines of code and there needs to be test cases first. I can find the explicit message if you don't recall) I ended up reverting the change in lack of test cases though.. ;) The political rift is largely that the python script kiddies and labelCompare() are doing things differently than what RPM is doing. The issue is solely that there are different conventions for missing values that prevent otherwise identical code from being collapsed through re-factoring. But its not my job to teach script kiddies how to program or otherwise relieve them of their ignorance. Lord knows I've tried to do so for years and years and years. *shrug*. Meanwhile I no longer give a rat's ass crap about legacy. But you might want to coordinate the change with Ander's and smart before we have Yet Another Food Fight in the rpm-python cafeteria. There's the obvious issue of legacy/API compatibilty, but how to deal with it is hard to fully decide in the python bindings though, and practicality of these functions and benefit of getting same behaviour as RPM are hard to argue with (regardless of smart, especially if wanting to support any different version comparision scheme than using the order of EVRD). The python bindings really should get some attention. first of all just cleaning up and fixing any existing issues. Moving past that, doing new development on features and functionality, legacy compatibility for bindings and/or any tools (such as smart) using them will both get painful if wanting to ensure compatibility with ie. rpm.org as well.. So yeah, implementing function in python bindings are trivial, the benefits quite obvious, fitting it into smart OTOH will require more thinking, discussion and coordination.. For smart in Mandriva, I really want to make sure of consistent behaviour with urpmi and rpm itself, which makes it important for me at least to be able to switch back and forth between the two. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
On Jan 27, 2011, at 2:47 PM, Per Øyvind Karlsen wrote: d'oh, sent with wrong email address.. 2011/1/27 Per Øyvind Karlsen peroyv...@mandriva.org: 2011/1/27 Jeff Johnson n3...@mac.com: There's a deep political rift aka labelCompare() involving missing values that needs to be sorted through here. The same political rift affects your fix with missing values (my comment was something arch like You changed too many lines of code and there needs to be test cases first. I can find the explicit message if you don't recall) I ended up reverting the change in lack of test cases though.. ;) The political rift is largely that the python script kiddies and labelCompare() are doing things differently than what RPM is doing. The issue is solely that there are different conventions for missing values that prevent otherwise identical code from being collapsed through re-factoring. But its not my job to teach script kiddies how to program or otherwise relieve them of their ignorance. Lord knows I've tried to do so for years and years and years. *shrug*. Meanwhile I no longer give a rat's ass crap about legacy. But you might want to coordinate the change with Ander's and smart before we have Yet Another Food Fight in the rpm-python cafeteria. There's the obvious issue of legacy/API compatibilty, but how to deal with it is hard to fully decide in the python bindings though, and practicality of these functions and benefit of getting same behaviour as RPM are hard to argue with (regardless of smart, especially if wanting to support any different version comparision scheme than using the order of EVRD). There's all sorts of issues, and unless you know the hysteria, you will NOT see them in the code. With a fork and FUD everywhere, rpm-python has been essentially dead in the water for 5+ years. I do not see that changing, and is in fact why JavaScript is the chosen binding language @rpm5.org. Too bad for Python script kiddies, who will have to make their own way forward with whatever version of RPM they choose. There is explicit and serious negative interest -- not from me -- in using @rpm5.org. Have fun! Not my problem mon. The python bindings really should get some attention. first of all just cleaning up and fixing any existing issues. Moving past that, doing new development on features and functionality, legacy compatibility for bindings and/or any tools (such as smart) using them will both get painful if wanting to ensure compatibility with ie. rpm.org as well.. From an engineering POV yes, the rpm-python bindings @rpm5.org need to be overhauled. I've said this many many times over the last few years and there is NO detectable interest. So I do JavaScript (with GPSEE - rpmlib) instead. Life's too short. So yeah, implementing function in python bindings are trivial, the benefits quite obvious, fitting it into smart OTOH will require more thinking, discussion and coordination.. For smart in Mandriva, I really want to make sure of consistent behaviour with urpmi and rpm itself, which makes it important for me at least to be able to switch back and forth between the two. Go for it! I did in fact write rpm-python bindings, am fully cpabale of assisting with the engineering work. But I will NOT be smeared by FUD politics any further. I wish my privacy. 73 de Jeff__ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
2011/1/27 Jeff Johnson n3...@mac.com: On Jan 27, 2011, at 3:12 PM, Per Øyvind Karlsen wrote: Yes its all very silly and stoopid. But I'll rot in hell before I get blamed for You broke yum by changing rpm-python @rpm5.org! Which was the suggestion that Per Oyvind coordinate a tricky change first. Don't worry on labelCompare(), I find it rather inpractical and tedious to use compared to just passing EVR strings to evrCompare() for rpmEVRparse to take care of parsing it, rather than parsing it myself with ie. regexp and passing the parts of it as a tuple.. Well I delivered essentially that same statement to ssopw...@redhat.com within 24 hours when he crufted up labelCompare() way back when. Life's too short to argue about whether 0 or NULL or or whatever is The One Truly Pythonic Way to write code. I'm afraid of touch existing functionality in the python bindings myself already anyways due to concern about legacy compatibility, by adding new functions I at least won't break anything existing, causing troubles for others.. ;) Hint: test cases. How convenient, I now can just convert the existing test case with labelCompare() in python/test/test_rpm.py to use evrCompare()! ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
If you really want bindings onto the (ancient abandoned-but-not-urpmi)
hdlist concatenated format, then the magic incantations to strip out
tags that are not desired should be added as a python method as well.
The magic incantations to drop an immutable region so that tags
can truly be added/deleted/modified (not just appended) is
in a CVS Attic, likely in the tools/ subdirectory. I've
copied last known good genhdlist.c to
http://wraptastic.org/pub/jbj/genhdlist.c
Ideally, for generality, a black-list tagnum tuple array should
be passed to a tag filter method that returns a trimmed header
(with immutable region restored, use headerReload()) before
calling the write methods that you just added.
You might suggest all of the above to TurboLinux, they can't possibly
be happy with their existing methods to create a hdlist (or they would
not have attempted adding the write methods). FWIW, if they are not
doing the magic incantations to remove what is deemed bloat in
headers, then they are likely not decreasing the size of hdlist
correctly,
immutable == immutable header regions, and its not exactly obvious
how to crack the concrete, all by design.
I cannot tell without examining what headers are passed into the new
methods.
hth
73 de Jeff
On Dec 6, 2008, at 9:52 AM, Per Øyvind Karlsen wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Per Øyvind Karlsen
Root: /v/rpm/cvs Email: [EMAIL PROTECTED]
Module: rpm Date: 06-Dec-2008 15:52:14
Branch: HEAD Handle: 2008120614521400
Modified files:
rpm CHANGES
rpm/python header-py.c header-py.h rpmmodule.c
Log:
python: add writeHeaderListToFD() writeHeaderListToFile().
(improved version of TurboLinux patch)
Summary:
RevisionChanges Path
1.2668 +2 -0 rpm/CHANGES
1.98+75 -0 rpm/python/header-py.c
1.17+10 -0 rpm/python/header-py.h
1.175 +4 -0 rpm/python/rpmmodule.c
patch -p0 '@@ .'
Index: rpm/CHANGES
=
=
=
=
=
=
==
$ cvs diff -u -r1.2667 -r1.2668 CHANGES
--- rpm/CHANGES6 Dec 2008 13:57:11 - 1.2667
+++ rpm/CHANGES6 Dec 2008 14:52:14 - 1.2668
@@ -1,5 +1,7 @@
5.2a2 - 5.2a3:
+- proyvind: python: add writeHeaderListToFD()
writeHeaderListToFile().
+ (improved version of TurboLinux patch)
- proyvind: rpm4compat: disable warnings about unused variables.
- proyvind: Mandriva: Always treat file conflicts during
install (rpm -i)
as errors. (dont-filter-install-file-conflicts)
@@ .
patch -p0 '@@ .'
Index: rpm/python/header-py.c
=
=
=
=
=
=
==
$ cvs diff -u -r1.97 -r1.98 header-py.c
--- rpm/python/header-py.c 10 Oct 2008 21:51:35 - 1.97
+++ rpm/python/header-py.c 6 Dec 2008 14:52:14 - 1.98
@@ -670,6 +670,7 @@
PyObject * rpmReadHeaders (FD_t fd)
{
PyObject * list;
+PyObject * ret = NULL;
Header h;
hdrObject * hdr;
@@ -828,6 +829,80 @@
/**
*/
+PyObject * rpmWriteHeaders (PyObject * list, FD_t fd)
+{
+int count;
+
+if (!fd) {
+ PyErr_SetFromErrno(pyrpmError);
+ return NULL;
+}
+
+for(count = 0; count PyList_Size(list); count++){
+ Py_BEGIN_ALLOW_THREADS
+ const char item[] = Header;
+ const char * msg = NULL;
+ hdrObject * hdr = (hdrObject *)PyList_GetItem(list, count);
+ rpmRC rc = rpmpkgWrite(item, fd, hdr-h, msg);
+ if (rc != RPMRC_OK)
+ rpmlog(RPMLOG_ERR, %s: %s: %s : error code: %d\n,
rpmpkgWrite, item, msg, rc);
+ msg = _free(msg);
+ Py_END_ALLOW_THREADS
+}
+
+Py_RETURN_TRUE;
+}
+
+/**
+ */
+PyObject * rpmHeaderToFD(PyObject * self, PyObject * args,
+ PyObject * kwds)
+{
+FD_t fd;
+int fileno;
+PyObject * list;
+PyObject * ret;
+char * kwlist[] = {headers, fd, NULL};
+
+if (!PyArg_ParseTupleAndKeywords(args, kwds, Oi, kwlist,
list, fileno))
+ return NULL;
+
+fd = fdDup(fileno);
+
+ret = rpmWriteHeaders (list, fd);
+Fclose(fd);
+
+return list;
+}
+
+/**
+ */
+PyObject * rpmHeaderToFile(PyObject * self, PyObject * args,
+ PyObject *kwds)
+{
+char * filespec;
+FD_t fd;
+PyObject * list;
+PyObject * ret;
+char * kwlist[] = {headers, file, NULL};
+
+if (!PyArg_ParseTupleAndKeywords(args, kwds, Os, kwlist,
list, filespec))
+ return NULL;
+
+fd = Fopen(filespec, w.fdio);
+if (!fd) {
