Dennis Gilmore wrote:
> should be a absolute non starter, many installs happen interactively
> and would never get the file
At least 2 possible solutions:
(a) Write the file in Anaconda (at least for non-live installs, live
installs can and should get it from the spin kickstart), add a spoke to
Am 21.02.2014 23:30, schrieb Kevin Kofler:
> Colin Walters wrote:
>> That would mean that if we wanted to enable a new service by default,
>> admins wouldn't get it on upgrades.
>
> … which is how it should be. I don't want upgrades to mess with my set of
> enabled services. (E.g., I found it ext
Adam Williamson wrote:
> Very much +1. Putting it in kickstarts is a worse tying problem than
> putting it in a package: it ties this configuration mechanism to a
> system for creating deliverables, which is what kickstart is. We need to
> be moving away from having configuration in kickstarts, not
Colin Walters wrote:
> That would mean that if we wanted to enable a new service by default,
> admins wouldn't get it on upgrades.
… which is how it should be. I don't want upgrades to mess with my set of
enabled services. (E.g., I found it extremely rude from firewalld to enable
itself by defau
On Wed, 2014-02-19 at 18:03 -0500, Simo Sorce wrote:
> On Wed, 2014-02-19 at 15:12 -0600, Jon wrote:
> > As far as two (or more) fedora-presets' being installed at once, I
> > would say we allow the user to resolve the problem via .rpmnew
> >
> > The implication is "users would have to pick a -con
On Wed, 2014-02-19 at 15:12 -0600, Jon wrote:
> As far as two (or more) fedora-presets' being installed at once, I
> would say we allow the user to resolve the problem via .rpmnew
>
> The implication is "users would have to pick a -config/-preset package
> and then e.g. adjust things"
>
> This on
As far as two (or more) fedora-presets' being installed at once, I
would say we allow the user to resolve the problem via .rpmnew
The implication is "users would have to pick a -config/-preset package
and then e.g. adjust things"
This only works if the preset file has the same name across all the
On Wed, Feb 19, 2014 at 8:28 PM, Colin Walters wrote:
> On Wed, Feb 19, 2014 at 1:58 PM, Miloslav Trmač wrote:
>
> I think it's perfectly fine to have them conflict.
>
> You didn't reply to the part of my mail where I was describing the
> "Workstation on a Server" case.
>
Sorry, i read that as
On Wed, Feb 19, 2014 at 1:58 PM, Miloslav Trmač wrote:
I think it's perfectly fine to have them conflict.
You didn't reply to the part of my mail where I was describing the
"Workstation on a Server" case. Are you saying that you do not believe
this case is valid? Or that such users would
On Wed, 19.02.14 18:31, Colin Walters (walt...@verbum.org) wrote:
> On Wed, Feb 19, 2014 at 8:08 AM, Dennis Gilmore wrote:
> >
> >i think limiting to systemd is wrong. maybe the package should be
> >fedora-config- it could put other config snippets, or pull in
> >packages for the experience of th
On Wed, Feb 19, 2014 at 7:31 PM, Colin Walters wrote:
> On Wed, Feb 19, 2014 at 8:08 AM, Dennis Gilmore wrote:
>
> i think limiting to systemd is wrong. maybe the package should be
> fedora-config- it could put other config snippets, or pull in packages
> for the experience of the product.
>
> 1
On Wed, Feb 19, 2014 at 8:08 AM, Dennis Gilmore wrote:
i think limiting to systemd is wrong. maybe the package should be
fedora-config- it could put other config snippets, or pull in
packages for the experience of the product.
Yes, we could potentially obsolete the NetworkManager-config-server
- Original Message -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 18 Feb 2014 18:27:41 -0600
> Jon wrote:
>
> > Propose the unit file be packaged.
> >
> > * Releng does not want this in fedora-release.
> Not true, just not convinced its the best place for it. If it turn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Feb 2014 18:27:41 -0600
Jon wrote:
> Propose the unit file be packaged.
>
> * Releng does not want this in fedora-release.
Not true, just not convinced its the best place for it. If it turns out
it really is the best place then I will gla
Propose the unit file be packaged.
* Releng does not want this in fedora-release.
* Going in kickstart files is not happy.
We could call the package:
fedora-systemd-defaults-{base,workstation,server}
spins would call the file:
fedora-systemd-[spin]
remix would call the file:
[remix]-syste
On 2014-02-18 08:31, Matthias Clasen wrote:
On Tue, 2014-02-18 at 07:43 -0800, Adam Williamson wrote:
Very much +1. Putting it in kickstarts is a worse tying problem than
putting it in a package: it ties this configuration mechanism to a
system for creating deliverables, which is what kickstar
On Tue, 2014-02-18 at 07:43 -0800, Adam Williamson wrote:
>
> Very much +1. Putting it in kickstarts is a worse tying problem than
> putting it in a package: it ties this configuration mechanism to a
> system for creating deliverables, which is what kickstart is. We need to
> be moving away f
On 2014-02-14 09:25, Matthew Miller wrote:
On Fri, Feb 14, 2014 at 04:02:47PM +0100, Kevin Kofler wrote:
> That seems reasonable, and in that case, something like "fedora-presets"
> and "fedora-workstation-presets", etc., seems appropriate, and the
> corresponding release package could pull them
On Fri, Feb 14, 2014 at 04:02:47PM +0100, Kevin Kofler wrote:
> > That seems reasonable, and in that case, something like "fedora-presets"
> > and "fedora-workstation-presets", etc., seems appropriate, and the
> > corresponding release package could pull them in.
> What about my proposal to drop th
On Fri, Feb 14, 2014 at 15:22:26 +,
Colin Walters wrote:
That would mean that if we wanted to enable a new service by default,
admins wouldn't get it on upgrades. Which may be fine with the
traditional rpm-on-client-side installs.
I don't think that has to be the case. If the files i
On Fri, Feb 14, 2014 at 10:02 AM, Kevin Kofler
wrote:
Matthew Miller wrote:
That seems reasonable, and in that case, something like
"fedora-presets"
and "fedora-workstation-presets", etc., seems appropriate, and the
corresponding release package could pull them in.
What about my proposal t
Matthew Miller wrote:
> That seems reasonable, and in that case, something like "fedora-presets"
> and "fedora-workstation-presets", etc., seems appropriate, and the
> corresponding release package could pull them in.
What about my proposal to drop the preset directly onto the file system (but
in
On Fri, Feb 14, 2014 at 02:30:47AM -0600, Dennis Gilmore wrote:
> > > It really depends on how much it changes, I really do not like
> > > updating fedora-release very much.
> Its something that defines the release, which is done when the release
> is out, we did need to make changes recently to su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 13 Feb 2014 16:31:31 -0500
Adam Jackson wrote:
> On Thu, 2014-02-13 at 13:44 -0600, Dennis Gilmore wrote:
> > On Thu, 13 Feb 2014 17:39:40 +0100
> > Miloslav Trmač wrote:
> > > > Based on these arguments, I'd like to propose to move this fil
Colin Walters wrote:
> Right, it's a lame workaround for a lack of higher order structure
> beyond "set of packages".
For live images, the spin kickstarts could just drop that preset file
directly into the file system. For installers, it'd need some magic in
Anaconda though (unless we do away wi
On Thu, 2014-02-13 at 13:44 -0600, Dennis Gilmore wrote:
> On Thu, 13 Feb 2014 17:39:40 +0100
> Miloslav Trmač wrote:
> > > Based on these arguments, I'd like to propose to move this file to
> > > the fedora-release package (or elsewhere, if you can suggest better
> > > place).
> >
> >
> > I agr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 13 Feb 2014 17:39:40 +0100
Miloslav Trmač wrote:
> On Thu, Feb 13, 2014 at 2:53 PM, Václav Pavlín
> wrote:
>
> > Package systemd ships file 90-default.preset [1] (full path:
> > /usr/lib/systemd/system-preset/90-default.preset) which contai
On Thu, Feb 13, 2014 at 09:24:30AM -0700, Kevin Fenzi wrote:
> Well, if the products want to diverge on what to start/enable, we could
> do this I suppose. It's been suggested that we look at having a
> fedora-release for each product (with deps on those things the product
> advertises as part of t
On Thu, Feb 13, 2014 at 8:53 AM, Václav Pavlín
wrote:
Currently this file is part of systemd package which doesn't seem to
be
right. It contains default values specific for distribution, is not
part
of systemd upstream repository and is maintained downstream.
Right, it's a lame workarou
On Thu, 13.02.14 17:40, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > > Based on these arguments, I'd like to propose to move this file to
> > > the fedora-release package (or elsewhere, if you can suggest better
> > > place). This package is specific to Fedora distribution as well an
On Thu, Feb 13, 2014 at 09:24:30AM -0700, Kevin Fenzi wrote:
> On Thu, 13 Feb 2014 14:53:13 +0100
> Václav Pavlín wrote:
>
> > Hi,
>
> ...snip...
>
> > Based on these arguments, I'd like to propose to move this file to
> > the fedora-release package (or elsewhere, if you can suggest better
> >
On Thu, Feb 13, 2014 at 2:53 PM, Václav Pavlín wrote:
> Package systemd ships file 90-default.preset [1] (full path:
> /usr/lib/systemd/system-preset/90-default.preset) which contains rules for
> command 'systemctl preset NAME'.
>
> Based on these arguments, I'd like to propose to move this fil
On Thu, 13 Feb 2014 14:53:13 +0100
Václav Pavlín wrote:
> Hi,
...snip...
> Based on these arguments, I'd like to propose to move this file to
> the fedora-release package (or elsewhere, if you can suggest better
> place). This package is specific to Fedora distribution as well and
> contains Fe
Hi,
With current changes in Fedora regarding Fedora.next and productization
of Fedora distribution I would like to suggest following change.
Package systemd ships file 90-default.preset [1] (full path:
/usr/lib/systemd/system-preset/90-default.preset) which contains rules
for command 'system
34 matches
Mail list logo
