Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 04/02/2011 01:46 PM, Simon Lukasik wrote: I have finished a minimal work needed for rhn-client-tools on Debian. Changes are in rhn-client-tools-debian branch. Would You mind to take a review? I just read the code and have no problem. My comment: - in debUtils I would use python-dpkg. I know that it is long time dead, but dpkg does not change either. So you may not depend on it directly, but copy'n'paste it from that library. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 04/06/2011 03:39 PM, Miroslav Suchý wrote: On 04/02/2011 01:46 PM, Simon Lukasik wrote: I have finished a minimal work needed for rhn-client-tools on Debian. Changes are in rhn-client-tools-debian branch. Would You mind to take a review? I just read the code and have no problem. Merged to master. My comment: - in debUtils I would use python-dpkg. I know that it is long time dead, but dpkg does not change either. So you may not depend on it directly, but copy'n'paste it from that library. I will look at it. Thanks much. -- Simon LukasikSystems Management QA sluka...@redhat.com #satellite-qa ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 03/29/2011 05:36 PM, Simon Lukasik wrote: On 03/29/2011 08:41 AM, Miroslav Suchý wrote: On 03/29/2011 08:19 AM, Simon Lukasik wrote: (A) A big part of the code depends directly on python-rpm. We don't want 'import rpm' on Debian nor 'import apt' on Fedora. (B) /etc/sysconfig does not exist on Debian I would suggest to use /etc/default/rhn. /etc/default is Debian equivalent for /etc/sysconfig. More or less. The problem is not, that I cannot find an equivalent, the problem is, how to separate the code. (C) redhat-release does not exist on Debian /etc/debian_version or lsb_release -r or lsb_release -c So You suggest to require lsb from rhn-client-tools? It's not necessarily needed, but it would make things easier, yes. (D) Architecture names are slightly different Yeah, but we already have Debian architecture in DB and rhnpush count with it, right? Not exactly, but yes. Now we treat i686 as an i386. Which might not be ultimate solution for an Ubuntus. Potential solutions: Hello Mirek, I have finished a minimal work needed for rhn-client-tools on Debian. Changes are in rhn-client-tools-debian branch. Would You mind to take a review? I have introduced up2date_client.platform.getPlatfrom() which returns either 'rpm' or 'deb'. And other modules look up the value and decide what to do in a runtime. The 'rpm' is always default and I aimed not to change the behavior for rpm. So far I didn't touch /etc/sysconfig/rhn path. Nor the strings. It could be the next step. For testing on Debian you will need to install at least: python-ethtool, python-newt, python-dmidecode, python-apt, python-libxml2, lsb-release. And then install rhn-client-tools by: make PLATFORM=deb -f Makefile.rhn-client-tools install At least you should be able to register with Spacewalk-1.3+. Seeing the hardware profile, distribution information and package profile together with installation dates. Please make use of activation keys. So far we have no mechanism to associate channel to Debian/Ubuntu/Mint/Whatever. It could be tricky to parse that distribution information provided by lsb-release. I will follow up with *.deb packages, once these changes are merged upstream. Regards, My priorities: (1) Create a Debian patch, and apply it only when building the .deb package. It is easier for start, but the patch needs to be maintained. +1 (2) Modify upstream rhn-client-tools, to include bits for both: Debian Fedora and choose one during a build-time. +3 (3) Same as (2) but in run-time. (polymorphism). +2 (4) interleave with if-else: if getPlatform() == 'deb': import apt else: import rpm +2 (5) Still there is an option to write rhn-client-tools from scratch. (Design new interface). I doubt anybody likes that. -10 I see, build-time (2) has scored. I will look at this option focusing on Python's distutils. Assuming that sed (see current Makefile) and Python's preprocesor are not preferred ways. Will see, -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 03/29/2011 08:19 AM, Simon Lukasik wrote: (A) A big part of the code depends directly on python-rpm. We don't want 'import rpm' on Debian nor 'import apt' on Fedora. (B) /etc/sysconfig does not exist on Debian I would suggest to use /etc/default/rhn. /etc/default is Debian equivalent for /etc/sysconfig. More or less. (C) redhat-release does not exist on Debian /etc/debian_version or lsb_release -r or lsb_release -c (D) Architecture names are slightly different Yeah, but we already have Debian architecture in DB and rhnpush count with it, right? Potential solutions: My priorities: (1) Create a Debian patch, and apply it only when building the .deb package. It is easier for start, but the patch needs to be maintained. +1 (2) Modify upstream rhn-client-tools, to include bits for both: Debian Fedora and choose one during a build-time. +3 (3) Same as (2) but in run-time. (polymorphism). +2 (4) interleave with if-else: if getPlatform() == 'deb': import apt else: import rpm +2 (5) Still there is an option to write rhn-client-tools from scratch. (Design new interface). I doubt anybody likes that. -10 -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] The struggle with rhn-client-tools on Debian
On 03/29/2011 08:41 AM, Miroslav Suchý wrote: On 03/29/2011 08:19 AM, Simon Lukasik wrote: (A) A big part of the code depends directly on python-rpm. We don't want 'import rpm' on Debian nor 'import apt' on Fedora. (B) /etc/sysconfig does not exist on Debian I would suggest to use /etc/default/rhn. /etc/default is Debian equivalent for /etc/sysconfig. More or less. The problem is not, that I cannot find an equivalent, the problem is, how to separate the code. (C) redhat-release does not exist on Debian /etc/debian_version or lsb_release -r or lsb_release -c So You suggest to require lsb from rhn-client-tools? It's not necessarily needed, but it would make things easier, yes. (D) Architecture names are slightly different Yeah, but we already have Debian architecture in DB and rhnpush count with it, right? Not exactly, but yes. Now we treat i686 as an i386. Which might not be ultimate solution for an Ubuntus. Potential solutions: My priorities: (1) Create a Debian patch, and apply it only when building the .deb package. It is easier for start, but the patch needs to be maintained. +1 (2) Modify upstream rhn-client-tools, to include bits for both: Debian Fedora and choose one during a build-time. +3 (3) Same as (2) but in run-time. (polymorphism). +2 (4) interleave with if-else: if getPlatform() == 'deb': import apt else: import rpm +2 (5) Still there is an option to write rhn-client-tools from scratch. (Design new interface). I doubt anybody likes that. -10 I see, build-time (2) has scored. I will look at this option focusing on Python's distutils. Assuming that sed (see current Makefile) and Python's preprocesor are not preferred ways. Will see, -- Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
