Bug 1289226

Summary: RFE: multiplatform beakerlib: make rpm optional ?
Product: [Fedora] Fedora Reporter: Ondřej Pták <optak>
Component: beakerlibAssignee: Dalibor Pospíšil <dapospis>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: low    
Version: rawhideCC: azelinka, dapospis, dkutalek, mkyral, ohudlick, optak
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Quick and dirty patch to remove dependency on rpm none

Description Ondřej Pták 2015-12-07 16:52:58 UTC 
Description of problem:
beakerlib use rpm and rpm-python quite often, which make it harder to use on other platforms. It would be good to discuss possibility to make rpm optional, so it could be used for it's nice logging and functions even without rpm on system.

It looks that only one function is needed from rpm python module (rpm.ts in beakerlib-journalling). But there is a lot of occurrence of "rpm" command, usually as a check for some package.

For example I successfully run (only primitive) beakerlib test on windows in cygwin environment (rpm, rpm-python, python from cygwin, beakerlib copied).
On the other hand, on mac there seem to be much more problems. I wasn't able to install/compile rpm-python, but it probably should be possible. For me mac looks more problematic, for example tar is not compatible (need to install gtar), readlink has no "-f" option ... shortly, I fail to run beakerlib on OS X after several hours of effort.
Comment 1 David Kutálek 2015-12-08 00:06:41 UTC 
I would say we would encounter similar issues eg. on BSD systems.
BSD and Linux userlands differ and Beakerlib is not written to handle it.
Mac OS X is then more similar to BSD then Linux...

After a little hacking I was able to run Beakerlib test
on Mac OS X, given that:

 - using gnu variant of readlink:
 - using gnu variant of getopt
 - using quick and dirty patch to remove rpm dependency in journalling.py

$ brew install coreutils
$ brew install gnu-getopt
$ PATH="/usr/local/opt/coreutils/libexec/gnubin:/usr/local/Cellar/gnu-getopt/1.1.6/bin/:$PATH" make run

Of course, without rpm rlAssertRPM doesn't work.
Not sure what else could use it, but I guess not so much.

Proper solution to these problems are to be investigated,
but basically I would say we can run and it is doable.
Comment 2 David Kutálek 2015-12-08 00:09:13 UTC 
Created attachment 1103393 [details]
Quick and dirty patch to remove dependency on rpm

Quick, dirty, not complete. But enables basic Beakerlib run on Mac.
Comment 4 Ales Zelinka 2015-12-08 08:52:47 UTC 
What is the use-case for supporting macs and windows? If/when Beakerlib becomes multiplatform - how do I get access to these platforms so I can can my code on them?
Comment 9 Dalibor Pospíšil 2015-12-09 09:47:09 UTC 
Currently I am not in favour of making beakerlib multi-platform.
Anyway if we decide to support more platforms the best way would be to create patched packages for each of them. This would also mean (as Aleš noted) necessity of testing environment (HW, SW).
In case we decide not to support them we can still kind of 'tolerating' them by making the code compatible, e.g. ifdef statements. Of course without any SLA.
Comment 10 David Kutálek 2015-12-09 13:27:22 UTC 
(In reply to Dalibor Pospíšil from comment #9)
> Currently I am not in favour of making beakerlib multi-platform.
> Anyway if we decide to support more platforms the best way would be to
> create patched packages for each of them. This would also mean (as Aleš
> noted) necessity of testing environment (HW, SW).

Why do you think it would be best to have separate packages?
I think it would mean more management work actually.

> In case we decide not to support them we can still kind of 'tolerating' them
> by making the code compatible, e.g. ifdef statements. Of course without any
> SLA.

No problem with not getting first class support, 
we would manage and contribute ourself.
Comment 11 Dalibor Pospíšil 2015-12-10 09:30:26 UTC 
(In reply to David Kutálek from comment #10)
> No problem with not getting first class support, 
> we would manage and contribute ourself.

I thought about it a bit and I have thought up another possible way. As deployment on other platforms is needs special approach we could just distribute a non-applied patch for this. We could also include some platform specific scripts to ease the deployment.
Dedicated branch would be created where the patch would be maintained / created from.

This approach would not pollute main code so no runtime decisions would not be needed. I think we can start with this and merge it to the main code if it appears to be the right way.

On the other hand, if it is in main code we could also provide functions like rlIsPlatform, rlAssertDMG, ...

Once your final choice is beakerlib we should meet and discuss the final approach.
Comment 12 David Kutálek 2015-12-11 13:47:42 UTC 
Thanks, I am ok to discuss more later when our use case develops. 

Just for record, I think it look doable to:

 - package Beakerlib for Cygwin for Windows
 - package Beakerlib for brew install system for Mac