On 11/01/2013 08:05 PM, Toshio Kuratomi wrote:
In an attempt to get things done outside of the meeting :-)...
People seem to be telling me things about metapackage deps that aren't in
the draft. So something needs to be updated there.
I don't think it's easy question. Everyone speaks about something else.
Here's the puzzle pieces that I've been given:
metapackage example spec template:
* Main metapackage: Deps on some general scl packages
* SCL Runtime package: deps on scl-utils
* SCL build package: deps on scl-utils-build
Verified on few metapackages, which we created in the past:
* main metapackage
* BR scl-utils-build
* R essential packages like perl516-perl
* runtime
* BR scl-utils
* build
* there might be build dependencies, but don't have to
* build sub-package is tagged or installed, when you want to build
something into the collection. This package should be uninstalled after
build are finished.
metapackage section explanatory text:
* Main metapackage: The draft says the deps are "the packages essential to
this SCL." but I added that. Please tell me how to correct this if I am wrong.
* SCL build package: it says the dep on scl-utils-build is a should, not a must
mmaslano:
* The main metapackage requires scl-utils-build and the build package
requires the metapackage.
I was wrong, the dependency is not defined in our packages. The reason
is we tagged the main package into the buildroot, because tagged package
is needed anyway. The dependency would be redundant.
slavek:
* The runtime package must not dep on the main metapackage. That allows
people to install only a piece of the SCL.
As Slavek said, the runtime metapackage can't depend on main. User is
able to install only runtime, which requires minimal set of collection
or user can install only the main metapackage and pick manually what
else he wants. The minimal set was created in good faith it's really
minimal, but some people might see minimal differently.
* The main metapackage installs every general SCL package in the collection
as well as the SCL runtime package. (note that this conflicts with the
I looked into few metapackages. Everyone does it differently. Correct
way should be what Slavek said above.
Remi|Fedora:
* main metapackage has an implicit dep on the -runtime package
* I finally see where this is implicit. Each general SCL package has an
explicit dep on the -runtime package. As long as the main SCL
metapackage has a dep on at least one general SCL package, the
metapackage will implicitly dep on -runtime. This took me long enough
to see that I'd lean toward making this explicit or documenting the
chain of reasoning in the explanatory text.
* the main package is just a metapackage which install most of the
collection.
I concur.
geppetto:
* The Fedora SCL Guide documentation says the top level metapackage is
supposed to be minimal
: http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/sect-Package_Layout.html
toshio:
* Other packagers (not the scl maintainer) are going to want to create more
general scl packages that target an scl. Unless we are going to ban that
practice it will be hard for the scl metapackage to continuously update as
more general scl packages are added.
Here's the places that I see as needing to be clarified for me to continue
clarifying this section:
* What is the role of the metapackage? Does it aim to be complete or
minimal/essential/some smaller subset?
essential, which is hard to define ;-) Probably difference between
minimal and essential didn't bother our docs.
* Should the -runtime package *only* dep on scl-utils?
yeah, it's okay.
* Do we need to add both the dep chain from scl build package to main
metapackage and main metapackage to scl-utils-build or do we need to
simply make it explict that the SCL build package depends on
scl-utils-build?
I do not follow. Explicit dependency on scl-utils-build in -build is not
needed because you already has it in buildroot.
-Toshio
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
Marcela
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
