Fix bugs in tde_create_tarball macro #15

Birleştirildi
SlavekB 5 yıl önce feat/fix-create-tarball-installation içindeki 1 işlemeyi master ile birleştirdi
SlavekB 5 yıl önce yorum yaptı
Sahibi

When I try to use macro in knights module, I found two bugs. Both are fixed by this patch.

When I try to use macro in knights module, I found two bugs. Both are fixed by this patch.
MicheleC 5 yıl önce yorum yaptı
Sahibi

looks good

looks good
SlavekB PR/wip etiketini 5 yıl önce ekledi
SlavekB 5 yıl önce yorum yaptı
Poster
Sahibi

Tar command in cmake 2.8 does not allow all the options that we used. Therefore, further changes are needed.

Tar command in cmake 2.8 does not allow all the options that we used. Therefore, further changes are needed.
SlavekB 5 yıl önce yorum yaptı
Poster
Sahibi

The first part of the problem was discovered – in older CMake it is not possible to use -- for separating parameters from the file list for the tar command. After removing -- from parameters, the tarball is successfully created.

However, I have identified a second problem, which is why we probably have to use system tar instead of the CMake command tar. The files are packaged in the tar archive with the current owner / group, which means, for example, on my builder that they are owned by the user and the group pbuilder.

The first part of the problem was discovered – in older CMake it is not possible to use `--` for separating parameters from the file list for the tar command. After removing `--` from parameters, the tarball is successfully created. However, I have identified a second problem, which is why we probably have to use system tar instead of the CMake command tar. The files are packaged in the tar archive with the current owner / group, which means, for example, on my builder that they are owned by the user and the group `pbuilder`.
SlavekB 5 yıl önce yorum yaptı
Poster
Sahibi

Using external tar brings another problem. We need to finding out what implementation is available.

  1. GNU tar has parameters --owner=… --group=…
  2. BSD tar has parameters --uname=… --gname=…
Using external tar brings another problem. We need to finding out what implementation is available. 1. GNU tar has parameters `--owner=… --group=…` 2. BSD tar has parameters `--uname=… --gname=…`
deloptes 5 yıl önce yorum yaptı
Katkıcı

I thought this is default behavior: "[...] on my builder that they are owned by the user and the group pbuilder"

When you are not root it uses always the user, when you untar from that it will set the user with which you untar. Why should this be not acceptable?

When you untar as root ... you'll get the user that corresponds to the id that had 'pbuilder' or you'll see the id if such user does not exist.

I am consider myself newbie, but I was reading recently the specs of add_custom_command and discovered the ARGS argument. So what happens if you write something like

COMMAND ${CMAKE_COMMAND} 
   ARGS -E tar "cfz" "${CMAKE_CURRENT_BINARY_DIR}/${_target}" -- ${_files}

this was in cmake 3.0.2 doc

I thought this is default behavior: "[...] on my builder that they are owned by the user and the group pbuilder" When you are not root it uses always the user, when you untar from that it will set the user with which you untar. Why should this be not acceptable? When you untar as root ... you'll get the user that corresponds to the id that had 'pbuilder' or you'll see the id if such user does not exist. I am consider myself newbie, but I was reading recently the specs of add_custom_command and discovered the ARGS argument. So what happens if you write something like ``` COMMAND ${CMAKE_COMMAND} ARGS -E tar "cfz" "${CMAKE_CURRENT_BINARY_DIR}/${_target}" -- ${_files} ``` this was in cmake 3.0.2 doc
SlavekB 5 yıl önce yorum yaptı
Poster
Sahibi

The point is that a pure chroot is usually used when building packages, where the source files are unpacked with a some working UID / user name. The resulting binary packages should not refer to "some working UID" from the chroot that can be associated with a real user on users machines. Therefore, we need that the tarballs created during the build would refer to user root, instead of to some working UID / user name.

Mentioned -- should serve not for CMake, but for tar as a separator beetween tar options and file list. The CMake option ARGS therefore has a different purpose and is not a solution here.

The point is that a pure chroot is usually used when building packages, where the source files are unpacked with a some working UID / user name. The resulting binary packages should not refer to "some working UID" from the chroot that can be associated with a real user on users machines. Therefore, we need that the tarballs created during the build would refer to user root, instead of to some working UID / user name. Mentioned `--` should serve not for CMake, but for tar as a separator beetween tar options and file list. The CMake option ARGS therefore has a different purpose and is not a solution here.
SlavekB 5 yıl önce yorum yaptı
Poster
Sahibi

From commit d9d9396324, instead of the CMake tar command, system tar is used. This allows to add parameters for setting the files owner in tarball – the syntax for GNU tar and BSD tar is supported.

An option has been added to determine the compression program – gzip is as default.

From commit d9d9396324, instead of the CMake tar command, system tar is used. This allows to add parameters for setting the files owner in tarball – the syntax for GNU tar and BSD tar is supported. An option has been added to determine the compression program – gzip is as default.
SlavekB PR/wip etiketini 5 yıl önce sildi
SlavekB 5 yıl önce değişiklik isteğini kapattı
SlavekB feat/fix-create-tarball-installation dalı silindi 5 yıl önce
SlavekB 5 yıl önce R14.0.6 release kilometre taşına ekledi
Değişiklik isteği d9d9396324 olarak birleştirildi.
Bu konuşmaya katılmak için oturum aç.
Değerlendirici yok
Kilometre Taşı Yok
Atanan Kişi Yok
3 Katılımcı
Bildirimler
Bitiş Tarihi

Bitiş tarihi atanmadı.

Bağımlılıklar

Bağımlılık yok.

Referans: TDE/tde-cmake#15
Yükleniyor…
Henüz bir içerik yok.