Bug 1133479 - Review Request: vdsm-arch-dependencies - architecture specific dependencies for VDSM
Review Request: vdsm-arch-dependencies - architecture specific dependencies f...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nir Soffer
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-25 05:02 EDT by Yoav Kleinberger
Modified: 2015-09-15 23:15 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-20 10:34:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Yoav Kleinberger 2014-08-25 05:02:44 EDT
Spec URL: http://fedorapeople.org/~ykleinbe/vdsm-arch-dependencies/vdsm-arch-dependencies.spec
SRPM URL: http://fedorapeople.org/~ykleinbe/vdsm-arch-dependencies/vdsm-arch-dependencies-1.0-1.fc20.src.rpm
Description: This package maintains architecture specific dependencies of VDSM. On different architectures, VDSM requires different packages. This package provides a transparent way to handle this.

Fedora Account System Username: ykleinbe
Comment 1 Christopher Meng 2014-08-25 09:58:00 EDT
Is there any better approach? 

And, why does it have a license?
Comment 2 Matthias Runge 2014-08-26 04:33:11 EDT
Christopher,

each package has (to have) a license.

This is kind of hacky, but not forbidden.
Comment 3 Yoav Kleinberger 2014-08-26 06:22:41 EDT
Added full text of the GPL to package.
Comment 4 Christopher Meng 2014-08-26 10:01:33 EDT
(In reply to Matthias Runge from comment #2)
> Christopher,
> 
> each package has (to have) a license.
> 
> This is kind of hacky, but not forbidden.

I know. I only focused on why the package was given a license GPL without license texts included.

Now it's fine.

------------

Yoav, can't these conditional requirements be written into vdsm package itself?
Comment 5 Yoav Kleinberger 2014-09-28 04:07:55 EDT
we would like the vdsm package to be noarch. If it includes a binary, it will be arch-dependent.
Comment 6 Yaniv Bronhaim 2014-10-20 04:56:18 EDT
Hello Christopher, Thanks for reviewing this package.
Regarding your question, we currently have the requirements of this (vdsm-arch-dependencies) package in vdsm. This causes arch issues while vdsm should not be arch depended. This package helps vdsm to avoid having those dependencies if not required.

I refreshed the files and add few spec changes to fit fedora-review requirements. 

Please review:

Spec URL: http://bronhaim.fedorapeople.org/vdsm-arch-dependencies.spec
SRPM URL: http://bronhaim.fedorapeople.org/vdsm-arch-dependencies-1.0-2.fc20.src.rpm

Description: This package maintains architecture specific dependencies of VDSM. On different architectures, VDSM requires different packages. This package provides a transparent way to handle this.

Fedora Account System Username: ybronhei

Thanks.
Comment 7 Michael Schwendt 2014-10-20 05:52:34 EDT
> each package has (to have) a license.
> 
> This is kind of hacky, but not forbidden.

It is highly questionable to create an empty src.rpm for a meta package instead of creating the same meta package as a _subpackage_ of an already existing src.rpm. There is no vdsm related package where this could be added?

Please give more details about why this must be a new src.rpm and how this package or its name will be used.


| %global libname vdsm-arch-dependencies
| 
| Name:       %{libname}

Only to use %libname once in the entire spec file? So far, this package and the review request look like some half-baked idea. Has it been discussed anywhere before submitting a review request?
Comment 8 Yaniv Bronhaim 2014-10-21 04:06:30 EDT
This package helps vdsm to avoid adding requirement for packages which related to specific arch (in that case - dmidecode). when vdsm contains such requirement in the spec, we must sign vdsm package as arch specific. while requiring this meta package, vdsm and all its subpackages can be signed as noarch, except the vdsm-arch-dependencies.
we can't do it in one of the already available vdsm-* packages, because we want them also be signed as noarch 

Hope I clear enough..

What's wrong with using libname?
The idea behind is clear and already discussed (hope Dan can provide link about it). main goal - to avoid having arch dependency in vdsm-* packages.
Comment 9 Michael Schwendt 2014-10-21 04:43:44 EDT
> we can't do it in one of the already available vdsm-* packages,
> because we want them also be signed as noarch 

The "BuildArch" tag can be set per subpackage. Package "vdsm", for example, currently builds arch-specific packages as well as "noarch" packages. Creating a separate empty src.rpm for that only creates overhead.


> What's wrong with using libname?

Why define %{libname} and not use it anywhere?

And if %libname were to be used in the spec file, why not simply use %name instead?
Comment 11 Dan Kenigsberg 2015-06-01 10:00:58 EDT
We'll hide these requirement elsewhere.
Comment 12 Nir Soffer 2015-06-17 07:22:34 EDT
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #9)
> The "BuildArch" tag can be set per subpackage. Package "vdsm", for example,
> currently builds arch-specific packages as well as "noarch" packages.
> Creating a separate empty src.rpm for that only creates overhead.

Hi Michael,

I tried this combination (partial spec bellow):

#vdsm.spec

Name:           vdsm                                                                                                                                                    
BuildArch:      noarch

%package arch
Summary: Vdsm architecture specific dependencies                                                                                                                                
BuildArch: x86_64 ppc64 ppc64le
%ifarch x86_64
Requires: python-dmidecode
Requires: dmidecode
%endif
%ifnarch ppc64le
Requires: ceph-common
%endif

Building it, I get this error:

rpmbuild -ta  \
		   vdsm-4.17.0.tar.gz
error: line 321: Only noarch subpackages are supported: BuildArch: x86_64 ppc64 ppc64le
make: *** [rpm] Error 1

Since the idea of having separate src.rpm for the architecture specific package
was rejected, it seems that the only way is to make the main package architecture
specific.

Or do we have a better way to package?
Comment 13 Michael Schwendt 2015-06-17 08:12:49 EDT
> Name: vdsm
> BuildArch:      noarch

Once you set "BuildArch: noarch" in the base package, _everything_ becomes noarch, i.e. also build-time tests and all subpackages. Their dependencies can only be arch-independent, too. %ifarch won't work then. Build host may be of any arch. 

So, don't do that, if you want to retain full control about the buildarch of subpackages. Then you can set "BuildArch:" freely for individual subpackages, 
such as noarch metapackages. 

Currently, vdsm depends on libc (arch-specific) and contains lots of files. Even if you plan to get rid of the libc dep, there still would not be any strict need to includes tons of noarch files in the base package instead of some subpackage.


> Or do we have a better way to package?

1) Noarch contents from an arch-specific package can be moved to a noarch -common subpackage easily.

2) It's not even necessary to build any base package at all. An empty base %files section produces no binary rpm.

3) Src.rpm name could be "vdsm-suite", with no base package, and all built packages would be subpackages with full control over BuildArch per subpackage.
Comment 14 Nir Soffer 2015-08-20 10:34:40 EDT
We do not need the suggested vdsm-arch-dependencies. Instead we will have
arch specific vdsm package, and nonarch sub packages, as Michael suggested.

Note You need to log in before you can comment on or make changes to this bug.