Bug 9848

Summary: testimage/testexport: support permissions and attributes for package installation
Product: [QA/Testing] Runtime Testing Reporter: Mariano Lopez <mariano.lopez>
Component: generalAssignee: Unassigned <unassigned>
Status: RESOLVED OBSOLETE QA Contact:
Severity: enhancement    
Priority: Medium CC: joshuagloe, leonardo.sandoval.gonzalez, randy.macleod, sgw
Version: 5.99   
Target Milestone: Future   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Yes (doc changes required)

Description Mariano Lopez 2016-06-29 13:02:49 UTC
Currently the installation of packages during a runtime test is done using scp, this will change the owner and the attributes of the copied files, this can lead to problems in certain conditions.

I had a conversation with Joshua and it seems the easiest way to do it is to send the tars to the DUT and uncompress them in the target.
Comment 1 Mariano Lopez 2016-07-04 15:09:08 UTC
busybox's tar doesn't have options to preserve owner, permission or attributes, therefore we need to provide a tar binary.
Comment 2 Joshua Lock 2016-07-04 15:15:06 UTC
I know we talked about rsync before but I can't recall whether you tested it?

The rsync man page[1] says that rsync can:

"can  copy  locally,  to/from  another  host  over  any remote shell, or to/from a remote rsync daemon"

1. http://manpages.ubuntu.com/manpages/precise/en/man1/rsync.1.html
Comment 3 Mariano Lopez 2016-07-04 15:17:41 UTC
(In reply to comment #2)
> I know we talked about rsync before but I can't recall whether you tested it?
> 

I haven't tested it yet, the issue with rsync was that we needed to provide the binary in the target, but now we need to provide tar, so rsync becomes a viable option again. I'll try rsync next.
Comment 4 Joshua Lock 2016-07-04 15:19:23 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I know we talked about rsync before but I can't recall whether you tested it?
> > 
> 
> I haven't tested it yet, the issue with rsync was that we needed to provide
> the binary in the target, but now we need to provide tar, so rsync becomes a
> viable option again. I'll try rsync next.

My understanding of the manpage is that the binary shouldn't be required on the target, because rsync can copy "to/from  another  host  over  any remote shell" — thus I'd expect if we have rsync-native on the host we can rsync to the target.
Comment 5 Mariano Lopez 2016-07-04 15:20:50 UTC
(In reply to comment #4)
> My understanding of the manpage is that the binary shouldn't be required on
> the target, because rsync can copy "to/from  another  host  over  any remote
> shell" — thus I'd expect if we have rsync-native on the host we can rsync to
> the target.

I tested that, you need rsync in both hosts
Comment 6 Leonardo Sandoval Gonzalez 2017-08-23 16:31:46 UTC
unfortunately, the enhancement window is over, so moving it to 2.5.
Comment 7 Armin Kuster 2019-12-22 19:36:58 UTC
is this something we still need to test?
Comment 8 Randy MacLeod 2020-01-30 16:19:37 UTC
This doesn't seem to be a problem in our current workflow. Reopen if it becomes one.