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/...
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Marcela