fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
James Antill
james at fedoraproject.org
Mon Jun 30 20:03:44 UTC 2014
On Mon, 2014-06-30 at 15:42 -0400, Stephen Gallagher wrote:
> On 06/30/2014 03:38 PM, Josh Boyer wrote:
> > On Mon, Jun 30, 2014 at 3:30 PM, Stephen Gallagher
> > <sgallagh at redhat.com> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >> On 06/30/2014 03:08 PM, Josh Boyer wrote:
> >>> On Mon, Jun 30, 2014 at 2:59 PM, Stephen Gallagher
> >>> <sgallagh at redhat.com> wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>
> >>>> We're getting down to the wire on Fedora 21 and we need to
> >>>> nail down a few of the low-level release requirements.
> >>>>
> >>>> First of all, I'd like to formally propose that each of the
> >>>> products will have a fedora-release-$PRODUCT (and
> >>>> corresponding generic-release-$PRODUCT) package. This package
> >>>> will meet several needs (with magical hand-waving in this
> >>>> initial email).
> >>>>
> >>>> 1) All Products will add explicit Requires: to the
> >>>> fedora-release-$PRODUCT package so that they may define
> >>>> their minimal operating set properly. The presence or absence
> >>>> of this package on the system will indicate definitively
> >>>> which Product (if any) is operating here.
> >>>
> >>> Um... add Requires: where? Do you mean "All Products will
> >>> explicitly
> >>
> >> There will be Requires: as part of of the
> >> fedora-release-$PRODUCT package itself, therefore guaranteeing
> >> that a certain set of packages are always installed if the
> >> fedora-release-$PRODUCT package is.
> >>
> >>
> >>> include the fedora-release-$PRODUCT package in their kickstart
> >>> files"? The way you have it phrased now seems to imply that
> >>> some other package Requires: fedora-release-$PRODUCT which
> >>> seems very odd.
> >>>
> >>
> >> Let me give an example of the definition of
> >> fedora-release-server.
> >>
> >> Name: fedora-release-server Version: 21 Release: 1 Requires:
> >> cockpit Requires: rolekit
> >
> > OK, I misread. Though looking at this, I'm not sure it's really
> > the best solution here. It would certainly work, but it seems
> > cumbersome if your product requires more than a handful of
> > packages. Listing them all out would be superfluous since comps
> > should already do this. Relying on an explicitly listed handful to
> > bring in the rest via their RPM deps seems fragile. What you have
> > may work for Server but I'm skeptical it will be feasible for
> > Workstation.
> >
>
> I'd *LOVE* for yum/dnf to be able to have Requires: @yum-group,
> personally...
The problem here is that the meaning of @yum-group changes depending on
what repos. you have installed (and other things). And having dynamic
deps. is really bad.
You could maybe do something at rpmbuild time which would convert
@yum-group into the a list of packages, just to make the spec files
nicer (but this will then be one more magic thing that changes depending
on how/where/when you built the .src.rpm).
More information about the devel
mailing list