Re: Mass changes to packaging
On Mon, Aug 27, 2012 at 11:04 AM, Paul Howarth p...@city-fan.org wrote: On Sun, 26 Aug 2012 14:11:39 -0400 Tom Callaway tcall...@redhat.com wrote: This is the problem: In F18+, systemd now uses a system-wide policy (which can be overridden) to define what services are enabled, it is no longer hardcoded into each package's scriptlets. This is the feature that FESCo approved. You might not agree with it, but simply ignoring it is inappropriate. He's not ignoring it, he's saying that on F18+, the expansion of %systemd_post_enable should be exactly the same as the expansion of %systemd_post, i.e. not enabled by default and honoring whatever presets are set for the spin. This approach allows for spec files to be synced between all Fedora branches and generate the appropriate scriptlets for each release when built. This optimizes the migration path at the cost of making the final state ugly; I'm not sure that is a good bargain. After all, the F17 and F18 spec files will do _different_ things. I don't think it's unreasonable that the spec files themselves will be different - yes, that may be less convenient than having the same spec file for all branches, but allowing for the possibility for differences if why we have the branches in the first place. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 28 August 2012 09:39, Miloslav Trmač m...@volny.cz wrote: After all, the F17 and F18 spec files will do _different_ things. I don't think it's unreasonable that the spec files themselves will be different - yes, that may be less convenient than having the same spec file for all branches, but allowing for the possibility for differences if why we have the branches in the first place. I have the opposite feeling, having a single spec file for all the releases would be a *huge* benefit (at least for me) for all the things that can be updated in all releases. All the packages I mantain have %ifs defined for RHEL/CentOS variants and Fedora ones so they can be rebuilt everywhere and at least for the bacula part the rebuilt packages are used a lot [1]. This also helps fixing stuff once for all supported releases. This has led to a super-long list of %post sections for a single spec file; which is ok considering the SysV and systemd differences: http://pkgs.fedoraproject.org/cgit/bacula.git/tree/bacula.spec Adding another variant for f18+ can be done, but I would prefer into avoiding this. Thanks, --Simone [1] http://repos.fedorapeople.org/repos/slaanesh/bacula/README.txt -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, Aug 28, 2012 at 09:39:32AM +0200, Miloslav Trmač wrote: On Mon, Aug 27, 2012 at 11:04 AM, Paul Howarth wrote: He's not ignoring it, he's saying that on F18+, the expansion of %systemd_post_enable should be exactly the same as the expansion of %systemd_post, i.e. not enabled by default and honoring whatever presets are set for the spin. This approach allows for spec files to be synced between all Fedora branches and generate the appropriate scriptlets for each release when built. This optimizes the migration path at the cost of making the final state ugly; I'm not sure that is a good bargain. Once F20 rolls out and F17 goes EOL, maintainers can simply s/systemd_post_enable/systemd_post/ and then things won't be so ugly (or final). -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Scott Schmit i.g...@comcast.net writes: On Tue, Aug 28, 2012 at 09:39:32AM +0200, Miloslav TrmaÄ wrote: This optimizes the migration path at the cost of making the final state ugly; I'm not sure that is a good bargain. Once F20 rolls out and F17 goes EOL, maintainers can simply s/systemd_post_enable/systemd_post/ and then things won't be so ugly (or final). I remain of the opinion that it's not a good idea to remove all trace of the per-package enable decisions from the packages themselves. *If* we get to F20 without realizing that we'd like the packages to specify the defaults, then we can remove the redundant macro definitions. In the meantime, people who are arguing against this seem to be entirely too confident that the current design is perfect. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Sun, 26 Aug 2012 14:11:39 -0400 Tom Callaway tcall...@redhat.com wrote: On 08/25/2012 09:16 PM, Kevin Kofler wrote: 2. On UNRELEASED Fedora versions, i.e. Fedora 18 and higher, define %systemd_post as currently done, and %systemd_post_enable to the exact same thing. This is the problem: In F18+, systemd now uses a system-wide policy (which can be overridden) to define what services are enabled, it is no longer hardcoded into each package's scriptlets. This is the feature that FESCo approved. You might not agree with it, but simply ignoring it is inappropriate. He's not ignoring it, he's saying that on F18+, the expansion of %systemd_post_enable should be exactly the same as the expansion of %systemd_post, i.e. not enabled by default and honoring whatever presets are set for the spin. This approach allows for spec files to be synced between all Fedora branches and generate the appropriate scriptlets for each release when built. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/27/2012 05:04 AM, Paul Howarth wrote:
He's not ignoring it, he's saying that on F18+, the expansion of
%systemd_post_enable should be exactly the same as the expansion of
%systemd_post, i.e. not enabled by default and honoring whatever
presets are set for the spin.
Hmm, okay, this is clearer.
So, for Fedora 16 and 17:
1) %systemd_post should be redefined as follows:
%systemd_post() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/bin/systemctl daemon-reload /dev/null 21 || : \
fi \
%{nil}
2) Create a new macro defined like this:
%systemd_post_enable() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/bin/systemctl enable %{?*} /dev/null 21 || : \
fi \
%{nil}
Then, on Fedora 18+:
1) %systemd_post stays as it is currently defined:
%systemd_post() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/usr/bin/systemctl preset %{?*} /dev/null 21 || : \
fi \
%{nil}
2) Create a new macro defined like this:
%systemd_post_enable() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/usr/bin/systemctl preset %{?*} /dev/null 21 || : \
fi \
%{nil}
(Note: I'm sure there is a way to actually have this macro just call the
%systemd_post() macro, but I couldn't get the args to pass through.)
***
The result is that if your package is permitted to enable a service by
default in F16/F17, it can use %systemd_post_enable foo.service on
F16/F17/F18. It is essentially a no-op on F18+ (identical to
%systemd_post foo.service).
Lennart, this seems like a good path forward, please let me know how
you'd like to proceed (I can patch this in Fedora and push updates, but
you might want to handle it yourself).
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/25/2012 09:16 PM, Kevin Kofler wrote: 2. On UNRELEASED Fedora versions, i.e. Fedora 18 and higher, define %systemd_post as currently done, and %systemd_post_enable to the exact same thing. This is the problem: In F18+, systemd now uses a system-wide policy (which can be overridden) to define what services are enabled, it is no longer hardcoded into each package's scriptlets. This is the feature that FESCo approved. You might not agree with it, but simply ignoring it is inappropriate. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/26/2012 11:41 PM, Tom Callaway wrote: On 08/25/2012 09:16 PM, Kevin Kofler wrote: 2. On UNRELEASED Fedora versions, i.e. Fedora 18 and higher, define %systemd_post as currently done, and %systemd_post_enable to the exact same thing. This is the problem: In F18+, systemd now uses a system-wide policy (which can be overridden) to define what services are enabled, it is no longer hardcoded into each package's scriptlets. This is the feature that FESCo approved. You might not agree with it, but simply ignoring it is inappropriate. If you redefine two macros to be the same in F18+, how is the policy being ignored? Are you objecting to the name of the macro? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Tom Callaway wrote: Unfortunately, it isn't that easy. Please note that I had to redefine %systemd_post for F16 and F17 in order to simplify it to that. The %systemd_post_enable logic doesn't apply in F18+, because there is no longer any explicit enablement at the package level. The two are not synonymous. You're still missing his point! He's saying that %systemd_post and %systemd_post_enable should do the exact SAME thing on F18, i.e. enable the service if and only if the policy says it should be enabled, no matter what the package says. In other words, make the _enable suffix only relevant for F16 and F17 and ignored entirely on F18. That's also how I'd do things. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/25/2012 07:09 PM, Kevin Kofler wrote: He's saying that %systemd_post and %systemd_post_enable should do the exact SAME thing on F18, i.e. enable the service if and only if the policy says it should be enabled, no matter what the package says. In other words, make the _enable suffix only relevant for F16 and F17 and ignored entirely on F18. I suppose that's up to the systemd maintainer, but I don't think it makes sense to be making that sort of significant change to already released Fedora versions. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Tom Callaway wrote:
On 08/25/2012 07:09 PM, Kevin Kofler wrote:
He's saying that %systemd_post and %systemd_post_enable should do the
exact SAME thing on F18, i.e. enable the service if and only if the
policy says it should be enabled, no matter what the package says. In
other words, make the _enable suffix only relevant for F16 and F17 and
ignored entirely on F18.
I suppose that's up to the systemd maintainer, but I don't think it
makes sense to be making that sort of significant change to already
released Fedora versions.
Huh? I don't follow you at all, and (I'm sorry, but) I get the impression
that you STILL don't understand what the proposal is.
Let me try to rephrase again how I understood Tom Lane's proposal:
1. On released Fedora versions, i.e. 16 and 17, define %systemd_post and
%systemd_post_enable as proposed by you:
%systemd_post() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/bin/systemctl daemon-reload /dev/null 21 || : \
fi \
%{nil}
%systemd_post_enable() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/bin/systemctl enable %{?*} /dev/null 21 || : \
fi \
%{nil}
2. On UNRELEASED Fedora versions, i.e. Fedora 18 and higher, define
%systemd_post as currently done, and %systemd_post_enable to the exact same
thing.
3. In the packaging guidelines, make packages replace the daemon-reload
snippet with %systemd_post and the enable snippet with %systemd_post_enable.
The result would be that:
(i) On released Fedora versions, nothing at all changes (!!!), we just
replaced a snippet by a macro which expands to the exact same snippet.
(ii) On upcoming Fedora versions, we implemented the feature just as if one
single %systemd_post macro had been used. The _enable suffix is ignored
entirely on upcoming Fedora versions (but NOT on released ones).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/22/2012 06:22 PM, Lennart Poettering wrote:
On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote:
Lennart Poettering mzerq...@0pointer.de writes:
On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote:
I'll add a me too here.
Any word on if the macros can/will be back-ported to f16/f17?
The preset logic is actually already available in F17, so we could
theoretically backport that, but this would mean we'd also have to
create and maintain a preset policy file for F17, and that's the bit I
am not sure i'd like to do.
Without the preset policy the macros would only turn things off after
installation, never on.
What I would want to see in F16/F17 is macros that exactly duplicate the
previously-standard snippets they are supposed to replace. Nobody is
suggesting that the preset stuff ought to go into the released branches;
only that we don't want to have to maintain different specfile versions
for the different branches. And if these things are macros, we should
not have to.
The thing is that previously we had to different snippets, one for
enabling a service after installation, one for leaving it disabled. With
the macros there is only one which checks the preset policy whether
something should be enabled. Hence we can't really map the old logic to
the new macros, I fear.
I think we can manage this. In the F17 and F16 systemd, provide the same
macros, except:
1) %systemd_post should be redefined as follows:
%systemd_post() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/bin/systemctl daemon-reload /dev/null 21 || : \
fi \
%{nil}
2) Create another macro:
%systemd_post_enable() \
if [ $1 -eq 1 ] ; then \
# Initial installation \
/bin/systemctl enable %{?*} /dev/null 21 || : \
fi \
%{nil}
3) We'll adjust the guidelines like this:
If your service is explicitly enabled by default in Fedora 16 or 17, and
you wish to have a shared spec file, you will need to add a
conditionalized call to the %systemd_post_enable macro, as follows:
%post
%if %{defined fc16} || %{defined fc17}
%systemd_post_enable apache-httpd.service
%else
%systemd_post apache-httpd.service
%endif
Thoughts?
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Tom Callaway tcall...@redhat.com writes:
3) We'll adjust the guidelines like this:
If your service is explicitly enabled by default in Fedora 16 or 17, and
you wish to have a shared spec file, you will need to add a
conditionalized call to the %systemd_post_enable macro, as follows:
%post
%if %{defined fc16} || %{defined fc17}
%systemd_post_enable apache-httpd.service
%else
%systemd_post apache-httpd.service
%endif
Surely F18 could define %systemd_post_enable as a synonym for
%systemd_post. The entire point of this thread is to make things
simpler for packager maintainers, not load them down with cross-branch
differences. (If I wanted to have a version-dependent %if in there,
I could have done that without any help from the macros.)
A larger point here is that I don't think it's an amazingly good idea to
be removing all trace of whether a package thinks it's supposed to be
enabled by default. Having two separate macros is not a bad thing IMO,
even if they happen to have the same expansion today.
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/23/2012 12:16 PM, Tom Lane wrote: Surely F18 could define %systemd_post_enable as a synonym for %systemd_post. The entire point of this thread is to make things simpler for packager maintainers, not load them down with cross-branch differences. (If I wanted to have a version-dependent %if in there, I could have done that without any help from the macros.) Unfortunately, it isn't that easy. Please note that I had to redefine %systemd_post for F16 and F17 in order to simplify it to that. The %systemd_post_enable logic doesn't apply in F18+, because there is no longer any explicit enablement at the package level. The two are not synonymous. FWIW, I actually think that doing it as a preset policy makes more sense, because it allows for that decision to be made depending on the usecase, with a set of system-wide defaults provided by Fedora that can be overridden. It also simplifies the scriptlets significantly in the F18+ universe. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
I'll add a me too here. Any word on if the macros can/will be back-ported to f16/f17? Has someone filed a RFE for Fedora systemd? Or would the systemd package maintainers chime in here? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote: I'll add a me too here. Any word on if the macros can/will be back-ported to f16/f17? Has someone filed a RFE for Fedora systemd? Or would the systemd package maintainers chime in here? The preset logic is actually already available in F17, so we could theoretically backport that, but this would mean we'd also have to create and maintain a preset policy file for F17, and that's the bit I am not sure i'd like to do. Without the preset policy the macros would only turn things off after installation, never on. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Lennart Poettering mzerq...@0pointer.de writes: On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote: I'll add a me too here. Any word on if the macros can/will be back-ported to f16/f17? The preset logic is actually already available in F17, so we could theoretically backport that, but this would mean we'd also have to create and maintain a preset policy file for F17, and that's the bit I am not sure i'd like to do. Without the preset policy the macros would only turn things off after installation, never on. What I would want to see in F16/F17 is macros that exactly duplicate the previously-standard snippets they are supposed to replace. Nobody is suggesting that the preset stuff ought to go into the released branches; only that we don't want to have to maintain different specfile versions for the different branches. And if these things are macros, we should not have to. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote: Lennart Poettering mzerq...@0pointer.de writes: On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote: I'll add a me too here. Any word on if the macros can/will be back-ported to f16/f17? The preset logic is actually already available in F17, so we could theoretically backport that, but this would mean we'd also have to create and maintain a preset policy file for F17, and that's the bit I am not sure i'd like to do. Without the preset policy the macros would only turn things off after installation, never on. What I would want to see in F16/F17 is macros that exactly duplicate the previously-standard snippets they are supposed to replace. Nobody is suggesting that the preset stuff ought to go into the released branches; only that we don't want to have to maintain different specfile versions for the different branches. And if these things are macros, we should not have to. The thing is that previously we had to different snippets, one for enabling a service after installation, one for leaving it disabled. With the macros there is only one which checks the preset policy whether something should be enabled. Hence we can't really map the old logic to the new macros, I fear. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Thu, Aug 23, 2012 at 01:22:27AM +0200, Lennart Poettering wrote: On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote: Lennart Poettering mzerq...@0pointer.de writes: On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote: I'll add a me too here. Any word on if the macros can/will be back-ported to f16/f17? The preset logic is actually already available in F17, so we could theoretically backport that, but this would mean we'd also have to create and maintain a preset policy file for F17, and that's the bit I am not sure i'd like to do. Without the preset policy the macros would only turn things off after installation, never on. What I would want to see in F16/F17 is macros that exactly duplicate the previously-standard snippets they are supposed to replace. Nobody is suggesting that the preset stuff ought to go into the released branches; only that we don't want to have to maintain different specfile versions for the different branches. And if these things are macros, we should not have to. The thing is that previously we had to different snippets, one for enabling a service after installation, one for leaving it disabled. With the macros there is only one which checks the preset policy whether something should be enabled. Hence we can't really map the old logic to the new macros, I fear. Well, you could have two macros -- pre-F18 they do what they do now, F18+, they do the same thing and defer to the policy. Another way to go is to create 2 macros for pre-F18 that are no-ops F18+ and make the F18+ macros no-ops pre-F18. Then have packagers put both in (or maintain two versions of the spec file). It's kind of ugly, but it sounds like it's that or wait until F20 before maintainers start picking up the new macros (unless they already have different spec files per Fedora version). HTH -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ I just received about a dozen bugs like this: Yep, someone has taken it upon themselves to mass-file a bunch of unnecessary tickets. When FPC makes guidelines changes, they aren't generally accompanied by some mandate that existing packages be changed. In fact, I can't think of a time when a change was made retroactive. If there was something that had to change in a bunch of packages, we'd at least try to organize a labor pool to get that done without having to endlessly bug every package maintainer. So someone I've never heard of is filing a bunch of tickets telling everyone to change their packages. I really can't imagine how that's supposed to inspire a lot of joy. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging (was: Re: New: Introduce new systemd-rpm macros in [...])
Richard W.M. Jones rjo...@redhat.com writes: I just received about a dozen bugs like this: On Tue, Aug 21, 2012 at 02:16:42PM +, bugzi...@redhat.com wrote: https://bugzilla.redhat.com/show_bug.cgi?id=850364 [...] Summary: Introduce new systemd-rpm macros in watchdog spec file [...] Yeah, I got a couple of those too. I do not wish to make the proposed changes, nor would I be happy if someone made them for me, because I do not want to have unnecessary divergences between the spec files for different Fedora branches. That not only creates issues for cherry-picking updates, but it means that I can't for example test-build a rawhide SRPM on my F16 work machine. If the incompatibility is *necessary* then I'll put up with it, but as far as I can see this is only cosmetic at this point. I'd like to see these macros back-ported into F17 and F16 RPM to remove this objection. If that doesn't happen, I'm going to resist using them in my spec files until they are in all active Fedora branches. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/21/2012 05:04 PM, Tom Lane wrote: I'd like to see these macros back-ported into F17 and F16 RPM to remove this objection. If that doesn't happen, I'm going to resist using them in my spec files until they are in all active Fedora branches. regards, tom lane +1 --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Jason L Tibbitts III (ti...@math.uh.edu) said: RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ I just received about a dozen bugs like this: Yep, someone has taken it upon themselves to mass-file a bunch of unnecessary tickets. When FPC makes guidelines changes, they aren't generally accompanied by some mandate that existing packages be changed. In fact, I can't think of a time when a change was made retroactive. If there was something that had to change in a bunch of packages, we'd at least try to organize a labor pool to get that done without having to endlessly bug every package maintainer. This stems from a request of mine, and is therefore my fault.. Presets are a valuable new feature for both distribution constructors and administrators - rather than having a single hardcoded policy *in the packages* about what starts and doesn't start (and requires rebuilding to fix), presets allow an easy way for: - administrators - provisioners - spin maintainers to easily define what should shouldn't be running for their install. However, it will take some work to get that done across the repository of packages, so I requested that Vaclav, Lukas, Michal, and any others look into what is needed to do this work in the repository. I had intended for them to provide patches and an offer to commit, but I didn't communicate that clearly to them. Apologies to those worried by these requests, and to Vaclav, Lukas, and Michal for anything that comes their way. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/21/2012 10:04 AM, Tom Lane wrote: Richard W.M. Jones rjo...@redhat.com writes: I just received about a dozen bugs like this: On Tue, Aug 21, 2012 at 02:16:42PM +, bugzi...@redhat.com wrote: https://bugzilla.redhat.com/show_bug.cgi?id=850364 [...] Summary: Introduce new systemd-rpm macros in watchdog spec file [...] Yeah, I got a couple of those too. I do not wish to make the proposed changes, nor would I be happy if someone made them for me, because I do not want to have unnecessary divergences between the spec files for different Fedora branches. That not only creates issues for cherry-picking updates, but it means that I can't for example test-build a rawhide SRPM on my F16 work machine. If the incompatibility is *necessary* then I'll put up with it, but as far as I can see this is only cosmetic at this point. I'd like to see these macros back-ported into F17 and F16 RPM to remove this objection. If that doesn't happen, I'm going to resist using them in my spec files until they are in all active Fedora branches. I see no reason why these macros couldn't be back-ported to F17 F16, they just wouldn't do the preset functionality. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, Aug 21, 2012 at 11:59:29 -0400, Bill Nottingham nott...@redhat.com wrote: Presets are a valuable new feature for both distribution constructors and administrators - rather than having a single hardcoded policy *in the packages* about what starts and doesn't start (and requires rebuilding to fix), presets allow an easy way for: Yeah, it gets old pretty quick when every time some packages get updated, one needs to enable or disable them again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Bruno Wolff III br...@wolff.to writes: On Tue, Aug 21, 2012 at 11:59:29 -0400, Bill Nottingham nott...@redhat.com wrote: Presets are a valuable new feature for both distribution constructors and administrators - rather than having a single hardcoded policy *in the packages* about what starts and doesn't start (and requires rebuilding to fix), presets allow an easy way for: Yeah, it gets old pretty quick when every time some packages get updated, one needs to enable or disable them again. Huh? That doesn't happen given the current (F16/F17) scriptlets AFAICS. They don't touch the service's enable state. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, Aug 21, 2012 at 12:25:32 -0400, Tom Lane t...@redhat.com wrote: Bruno Wolff III br...@wolff.to writes: On Tue, Aug 21, 2012 at 11:59:29 -0400, Bill Nottingham nott...@redhat.com wrote: Presets are a valuable new feature for both distribution constructors and administrators - rather than having a single hardcoded policy *in the packages* about what starts and doesn't start (and requires rebuilding to fix), presets allow an easy way for: Yeah, it gets old pretty quick when every time some packages get updated, one needs to enable or disable them again. Huh? That doesn't happen given the current (F16/F17) scriptlets AFAICS. They don't touch the service's enable state. Maybe what I am seeing is something different. I certainly have services turn back on after updates that I have disabled. sendmail is one example. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Le 21/08/2012 17:04, Tom Lane a écrit : I'd like to see these macros back-ported into F17 and F16 RPM to remove this objection. If that doesn't happen, I'm going to resist using them in my spec files until they are in all active Fedora branches. +1 Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/21/2012 02:52 PM, Richard W.M. Jones wrote: However, the person who is sending these bugs reports is (a) in a much better position to change the packages because they understand the problem and the solution, and (b) ought to take on this work because that's part of whatever feature/cleanup/etc they are proposing, instead of pushing part of that work off to everyone else. That's how I *initially* though the feature process worked as in the feature owner always has to do all the work. Then again I suspect not many maintainers will do this change since if I'm not mistaken it a) means they have to have separated spec files for F18 and b) will break everybody's upgrade path since if I'm not mistaken preset *resets* units enable/disablement *again* ( it happens when the legacy sysv to systemd migration takes place )... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, 21.08.12 16:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 08/21/2012 02:52 PM, Richard W.M. Jones wrote: However, the person who is sending these bugs reports is (a) in a much better position to change the packages because they understand the problem and the solution, and (b) ought to take on this work because that's part of whatever feature/cleanup/etc they are proposing, instead of pushing part of that work off to everyone else. That's how I *initially* though the feature process worked as in the feature owner always has to do all the work. Then again I suspect not many maintainers will do this change since if I'm not mistaken it a) means they have to have separated spec files for F18 and b) will break everybody's upgrade path since if I'm not mistaken preset *resets* units enable/disablement *again* ( it happens when the legacy sysv to systemd migration takes place )... No, presets don't reset existing enablement/disablement status. Presets only matter with the initial installation of a package and when a package is converted from sysv to systemd, but do not matter if a package already uses systemd unit files, or just converts non-macro scriptlets to macro scriptlets. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/21/2012 05:08 PM, Lennart Poettering wrote: On Tue, 21.08.12 16:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 08/21/2012 02:52 PM, Richard W.M. Jones wrote: However, the person who is sending these bugs reports is (a) in a much better position to change the packages because they understand the problem and the solution, and (b) ought to take on this work because that's part of whatever feature/cleanup/etc they are proposing, instead of pushing part of that work off to everyone else. That's how I*initially* though the feature process worked as in the feature owner always has to do all the work. Then again I suspect not many maintainers will do this change since if I'm not mistaken it a) means they have to have separated spec files for F18 and b) will break everybody's upgrade path since if I'm not mistaken preset*resets* units enable/disablement*again* ( it happens when the legacy sysv to systemd migration takes place )... No, presets don't reset existing enablement/disablement status. Presets only matter with the initial installation of a package and when a package is converted from sysv to systemd, but do not matter if a package already uses systemd unit files, or just converts non-macro scriptlets to macro scriptlets. But it's still necessary to keep two separate spec files ( F18 F18 ) + given the time of the packaging guideline changes and the branching happening the *day after* I tempted to put on my QA hat and argue this should only apply to F19 not F18 and from the looks of it the Red Hat's systemd *Team* is behind this which constitutes of what 5 - 10 people now so there should be sufficient manpower for those that requested this to actually make those changes themselves before F19 get's released... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
Bruno Wolff III br...@wolff.to writes: Tom Lane t...@redhat.com wrote: Bruno Wolff III br...@wolff.to writes: Yeah, it gets old pretty quick when every time some packages get updated, one needs to enable or disable them again. Huh? That doesn't happen given the current (F16/F17) scriptlets AFAICS. They don't touch the service's enable state. Maybe what I am seeing is something different. I certainly have services turn back on after updates that I have disabled. sendmail is one example. Hm, that seems pretty odd. sendmail's %post script is %post if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable sendmail.service /dev/null 21 || : /bin/systemctl enable sm-client.service /dev/null 21 || : /bin/systemctl daemon-reload /dev/null 21 || : fi which should not do anything on an update. It would auto-enable if you were installing the package when it was previously not present, but that isn't what you're describing. File a bug maybe? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
- Original Message - From: Bill Nottingham nott...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, August 21, 2012 5:59:29 PM Subject: Re: Mass changes to packaging Jason L Tibbitts III (ti...@math.uh.edu) said: RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ I just received about a dozen bugs like this: Yep, someone has taken it upon themselves to mass-file a bunch of unnecessary tickets. When FPC makes guidelines changes, they aren't generally accompanied by some mandate that existing packages be changed. In fact, I can't think of a time when a change was made retroactive. If there was something that had to change in a bunch of packages, we'd at least try to organize a labor pool to get that done without having to endlessly bug every package maintainer. This stems from a request of mine, and is therefore my fault.. Presets are a valuable new feature for both distribution constructors and administrators - rather than having a single hardcoded policy *in the packages* about what starts and doesn't start (and requires rebuilding to fix), presets allow an easy way for: - administrators - provisioners - spin maintainers to easily define what should shouldn't be running for their install. However, it will take some work to get that done across the repository of packages, so I requested that Vaclav, Lukas, Michal, and any others look into what is needed to do this work in the repository. I had intended for them to provide patches and an offer to commit, but I didn't communicate that clearly to them. Apologies to those worried by these requests, and to Vaclav, Lukas, and Michal for anything that comes their way. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Sorry for this mess. After a discussion, we have decided, that the best way would be to create bugs for every packages and then helping creating patches for specfiles. We want to give maintainers possibility to fix this on their own and because we want this change in all packages, creating bug seemed as a better option then spamming devel-list. Lukas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/21/2012 05:24 PM, Tom Lane wrote: which should not do anything on an update. It would auto-enable if you were installing the package when it was previously not present, but that isn't what you're describing. File a bug maybe? regards, tom lane It's a know ( and documented both in guidelines and release notes I believe ) nuance that if you upgrade between releases when the migration takes places ( legacy sysv initscript used in F15 native systemd unit introduced in F16 ) that you will need to enable/disable the relevant service again. This has caught some administrators by surprise and several bugs filed against relevant components ( either the service or systemd ) because of it thus I personally was a bit worried that users would have to go through all of that again which Lennart has pointed out will not happen. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, Aug 21, 2012 at 02:23:41PM -0400, Lukas Nykryn wrote: Sorry for this mess. After a discussion, we have decided, that the best way would be to create bugs for every packages and then helping creating patches for specfiles. Just to be clear, I had no problem at all with the bugs being filed, nor with the changes (which seem very sensible). I just pointed out it would be better if you actually fixed the packages, or at least offered to do that for packagers. We want to give maintainers possibility to fix this on their own and because we want this change in all packages, creating bug seemed as a better option then spamming devel-list. So my suggested wording for the bug report would be to give the packager a choice: either they do nothing now and can fix the package themselves, or they indicate that they want you to fix the package. If you want to do 'watchdog', please go ahead :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, Aug 21, 2012 at 13:24:53 -0400, Tom Lane t...@redhat.com wrote: which should not do anything on an update. It would auto-enable if you were installing the package when it was previously not present, but that isn't what you're describing. File a bug maybe? I'll need to keep better track. There are some cases where I do a reinstall. If there is version conflict for an update, I will sometimes remove the conflicting packages in order to test the update. Then later I'll put back removed packages after they have been updated so as not to conflict any more. So I might be seeing a combination of this case and upgrades between Fedora releases. I'm still hoping that the new feature will let me set a policy of nothing new getting installed should be on by default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, 21.08.12 13:24, Tom Lane (t...@redhat.com) wrote: Bruno Wolff III br...@wolff.to writes: Tom Lane t...@redhat.com wrote: Bruno Wolff III br...@wolff.to writes: Yeah, it gets old pretty quick when every time some packages get updated, one needs to enable or disable them again. Huh? That doesn't happen given the current (F16/F17) scriptlets AFAICS. They don't touch the service's enable state. Maybe what I am seeing is something different. I certainly have services turn back on after updates that I have disabled. sendmail is one example. Hm, that seems pretty odd. sendmail's %post script is %post if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable sendmail.service /dev/null 21 || : /bin/systemctl enable sm-client.service /dev/null 21 || : /bin/systemctl daemon-reload /dev/null 21 || : fi As a side note: the explicit daemon-reload command is unnecessary, as the reload is already implicitly done by enable. In fact, since there are two enable lines this will even result in a total of 3 full reloads. Shortening this to systemctl enable sendmail.service sm-client.service is much nicer. (That all said, instead of patching this it is probably a good idea to just port things over, to the new macros). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On 08/21/2012 01:01 PM, Richard W.M. Jones wrote: On Tue, Aug 21, 2012 at 02:23:41PM -0400, Lukas Nykryn wrote: Sorry for this mess. After a discussion, we have decided, that the best way would be to create bugs for every packages and then helping creating patches for specfiles. Just to be clear, I had no problem at all with the bugs being filed, nor with the changes (which seem very sensible). I just pointed out it would be better if you actually fixed the packages, or at least offered to do that for packagers. One thing to be careful of is compatibility with prior releases, and especially EPEL. I maintain a lot of package for EPEL and as much as possible I maintain the same spec on all branchs. Changes going into the master branch of my packages that I couldn't just merge into prior releases would be a problem for me. That caveat aside, I'm always happy to have help :) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, Aug 21, 2012 at 12:01 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Aug 21, 2012 at 02:23:41PM -0400, Lukas Nykryn wrote: Sorry for this mess. After a discussion, we have decided, that the best way would be to create bugs for every packages and then helping creating patches for specfiles. Just to be clear, I had no problem at all with the bugs being filed, nor with the changes (which seem very sensible). I just pointed out it would be better if you actually fixed the packages, or at least offered to do that for packagers. We want to give maintainers possibility to fix this on their own and because we want this change in all packages, creating bug seemed as a better option then spamming devel-list. So my suggested wording for the bug report would be to give the packager a choice: either they do nothing now and can fix the package themselves, or they indicate that they want you to fix the package. I am pleased that I got a bug report and not an involuntary patch, as it gives me a chance to take care of special cases and schedule things appropriately. I do agree, however, that offering to patch affected packages would also be a good gesture and a great way to help move the changes along. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
GH == Garrett Holmstrom gho...@fedoraproject.org writes: GH I am pleased that I got a bug report and not an involuntary patch, GH as it gives me a chance to take care of special cases and schedule GH things appropriately. I would much have preferred to receive an announcement about what should be done, some discussion about the best way to do it, and then some time to do it, after which tickets could be filed. Mass-filing a load of bugs just pisses people off, especially for something that isn't even mandatory. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
