https://bugzilla.redhat.com/show_bug.cgi?id=1428035 Petr Šabata <psabata@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(psabata@xxxxxxxxx | |m) | --- Comment #8 from Petr Šabata <psabata@xxxxxxxxxx> --- (In reply to Stephen Gallagher from comment #5) > (In reply to Petr Šabata from comment #3) > > * modular-release.spec:1-3 > > %global is generally preferred over %define; let's switch to that > > Done. Ack. > > * 90-default.preset: > > I'd remove the majority of the `enable' presets as nothing in the > > Base Runtime actually provides such functionality (or in some cases, > > unit files). Perhaps your filter mentioned in comment #1 didn't quite > > work? Or maybe I'm doing it wrong :) The one I'd remove include: > > - bluetooth (we only have the grouping target) > > - avahi-daemon (we don't have avahi) > > - cups (we don't have cups) > > - rsyslog (we don't have rsyslog) > > - syslog-ng (we don't have syslog-ng) > > - sysklogd (nothing in Fedora provides this) > > - gpm (we don't have gpm) > > - mcelog (we don't have mcelog) > > I think you're right that my filter may have been wrong. I've removed those. Ack. > > * modular-release.spec:44-48 > > I assume the reason for creating fedora-release and system-release-cpe > > under > > %{_prefix} (which is not what fedora-release does today) is to unify where > > all the release files are kept, as issue, issue.net, os-release and > > os.release.d are already there. Is that right? Note fedora-release > > doesn't do this. > > Yes, this is in preparation of the mythical future where empty /etc is > possible. It's been requested of the fedora-release package, but no one has > done the work yet. I figured it was okay for us to just do it. Okay, sounds good. > > * The standard fedora-release package also installs > > %{_prefix}/lib/os.release.d, plus some files/links under it. > > Don't we want it too? > > > > * Additionaly, it also installs %{_prefix}/lib/variant. Should we have it > > too? > > These are related. They exist specifically for dealing with the variants > like Fedora Server Edition vs. Fedora Workstation Edition. We don't need > these because we won't have variant versions of Base Runtime that need to > coexist in the same repository. > > (If you want an exhaustive explanation, read > https://sgallagh.wordpress.com/2016/03/18/sausage-factory-multiple-edition- > handling-in-fedora/ ) Alright. If it breaks something, we'll fix it. I've just noticed your %changelog entries are malformed; probably because your editor doesn't evaluate the macro when inserting the version. (In reply to Neal Gompa from comment #7) > (In reply to Petr Šabata from comment #4) > > (In reply to Neal Gompa from comment #2) > > > This should be prefixed with fedora- in its name. This is *not* generic. > > > > Note this package is only meant for the module-based compose and it is the > > only variant we're going to ship. Putting "fedora" in the name feels > > redundant to me, even if its content in Fedora dist-git includes files > > specific to Fedora. > > > > Also note this package won't be part of the traditional release -- it will > > be excluded from the compose. > > The name in the Summary indicates it's Fedora specific. All fedora branding > packages are named fedora-*. This should be no different. The idea here was that we wouldn't have to change the package name, bootstrap tags and installation & buildroot profiles when [re]building modules outside of Fedora. Of course this isn't the only way to achieve that; we could rename it or package this differently, if you really insist on having Fedora in the package name. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx