[gentoo-dev] [PATCH systemd.eclass 1/3] Add systemd_newtmpfilesd().
In pair with systemd_dotmpfilesd(), they will be the canonical functions
to install tmpfiles.d files.
I've talked with Sergei and we agreed to not move the functions around
but leave systemd.eclass as the canonical source of locations for
systemd-related files. The eclass will not introduce any dependencies or
other side effects.
Uses inline ( insinto; newins ) because of Diego's disapproval of
newinto function into eutils. Feel free to fix it as soon as we get such
a thing into EAPI and remove all EAPIs up to 4.
---
gx86/eclass/systemd.eclass | 14 ++
1 file changed, 14 insertions(+)
diff --git a/gx86/eclass/systemd.eclass b/gx86/eclass/systemd.eclass
index 1ddc9b0..4066e31 100644
--- a/gx86/eclass/systemd.eclass
+++ b/gx86/eclass/systemd.eclass
@@ -95,6 +95,20 @@ systemd_dotmpfilesd() {
)
}
+# @FUNCTION: systemd_newtmpfilesd
+# @USAGE: oldname newname.conf
+# @DESCRIPTION:
+# Install systemd tmpfiles.d file under a new name. Uses newins, thus it
+# is fatal in EAPI 4 and non-fatal in earlier EAPIs.
+systemd_newtmpfilesd() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ (
+ insinto /usr/lib/tmpfiles.d/
+ newins "${@}"
+ )
+}
+
# @FUNCTION: systemd_enable_service
# @USAGE: target service
# @DESCRIPTION:
--
1.7.11.1
[gentoo-dev] [PATCH systemd.eclass 2/3] tmpfiles.d: check for .conf suffix when installing.
This could help a few users avoid debugging why the rules don't work for
them.
---
gx86/eclass/systemd.eclass | 8
1 file changed, 8 insertions(+)
diff --git a/gx86/eclass/systemd.eclass b/gx86/eclass/systemd.eclass
index 4066e31..1ccaadc 100644
--- a/gx86/eclass/systemd.eclass
+++ b/gx86/eclass/systemd.eclass
@@ -89,6 +89,11 @@ systemd_newunit() {
systemd_dotmpfilesd() {
debug-print-function ${FUNCNAME} "${@}"
+ for f; do
+ [[ ${f} == *.conf ]] \
+ || die 'tmpfiles.d files need to have .conf suffix.'
+ done
+
(
insinto /usr/lib/tmpfiles.d/
doins "${@}"
@@ -103,6 +108,9 @@ systemd_dotmpfilesd() {
systemd_newtmpfilesd() {
debug-print-function ${FUNCNAME} "${@}"
+ [[ ${2} == *.conf ]] \
+ || die 'tmpfiles.d files need to have .conf suffix.'
+
(
insinto /usr/lib/tmpfiles.d/
newins "${@}"
--
1.7.11.1
[gentoo-dev] [PATCH systemd.eclass 3/3] Drop blockers for ancient systemd versions.
The current systemd versions don't provide the mentioned feature
anymore, so there's no point in blocking those who didn't as well.
---
gx86/eclass/systemd.eclass | 4
1 file changed, 4 deletions(-)
diff --git a/gx86/eclass/systemd.eclass b/gx86/eclass/systemd.eclass
index 1ccaadc..09275dc 100644
--- a/gx86/eclass/systemd.eclass
+++ b/gx86/eclass/systemd.eclass
@@ -30,10 +30,6 @@ case ${EAPI:-0} in
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac
-# Block systemd version without the migration helper.
-DEPEND="!
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Monday 20 August 2012 10:54:03 Rich Freeman wrote: > On Mon, Aug 20, 2012 at 10:43 AM, Alec Warner wrote: > > On Mon, Aug 20, 2012 at 4:27 PM, Rich Freeman wrote: > >> I agree with your point. I'm fine with setting deadlines and such, > >> but my main concern is that the first deadline shouldn't be two days > >> after it is announced. > > > > The tracker has been open since July 4th. > > Yes, and it does not contain any deadlines at all (not even the one > announced on the mailing list). glibc is on a known release period (~every 6 months). i posted some time ago that Gentoo will be rolling along as well: - have a version in the stable pipeline - have a version in the unstable pipeline - have a version in the masked pipeline as versions in the lower pipeline clear out, the next one will be moving into place. so while exact times haven't been posted (because i don't have them), glibc versions will continue to be released, so maintainers can't sit on their bugs. 2.15 has gone stable which means there's now room for 2.16 which has largely settled down. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Mon, Aug 20, 2012 at 10:43 AM, Alec Warner wrote: > On Mon, Aug 20, 2012 at 4:27 PM, Rich Freeman wrote: >> I agree with your point. I'm fine with setting deadlines and such, >> but my main concern is that the first deadline shouldn't be two days >> after it is announced. > > The tracker has been open since July 4th. > Yes, and it does not contain any deadlines at all (not even the one announced on the mailing list). There are bugs that have been open for years. If suddenly making some change breaks end-user systems the fact that a bug has been open for years isn't really justification. The first mention of "you must do this by this date" was on Friday, with the deadline being today. I'm fine with trying to push things through within reason (otherwise nothing gets done). However, the key part is "within reason." If that bug had a deadline announced two weeks ago I'd be less concerned. Rich
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Mon, Aug 20, 2012 at 4:27 PM, Rich Freeman wrote: > On Mon, Aug 20, 2012 at 10:14 AM, Alec Warner wrote: >> >> I think part of Mike's point is that time and time again has proven >> that the way to a mans heart^H^H^H^H to get things fixed is to break >> them. The aforementioned example of a tracker open for months with no >> progress is an example of halted progress. If we waited to fix all >> known issues prior to launch, then we would never launch. This is very >> common in software development. Some features are v2 features, some >> bugs are not worth fixing. Some bugs we will fix with a patch >> post-launch; I don't see how this is any different. >> > > I agree with your point. I'm fine with setting deadlines and such, > but my main concern is that the first deadline shouldn't be two days > after it is announced. The tracker has been open since July 4th. > > If the announcement were that we have a tracker and some languishing > bugs, and we'd like to push to get them closed in two weeks I'd feel > differently. I can't really say Mike is the shining example of how we should communicate; but then again, neither am I :) -A > > Rich >
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Mon, Aug 20, 2012 at 10:14 AM, Alec Warner wrote: > > I think part of Mike's point is that time and time again has proven > that the way to a mans heart^H^H^H^H to get things fixed is to break > them. The aforementioned example of a tracker open for months with no > progress is an example of halted progress. If we waited to fix all > known issues prior to launch, then we would never launch. This is very > common in software development. Some features are v2 features, some > bugs are not worth fixing. Some bugs we will fix with a patch > post-launch; I don't see how this is any different. > I agree with your point. I'm fine with setting deadlines and such, but my main concern is that the first deadline shouldn't be two days after it is announced. If the announcement were that we have a tracker and some languishing bugs, and we'd like to push to get them closed in two weeks I'd feel differently. Rich
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Mon, Aug 20, 2012 at 1:09 PM, Rich Freeman wrote: > On Sun, Aug 19, 2012 at 11:07 PM, Mike Frysinger wrote: >> On Sunday 19 August 2012 04:41:17 Luca Barbato wrote: >>> On 8/18/12 5:31 AM, Mike Frysinger wrote: >>> > i'll probably land it later this weekend/monday. >>> >>> Would be nice having a list of bugs open so people might have a look and >>> see if there is something big left. >> >> we've been making trackers for the glibc upgrades: >> https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.16 > > While trackers are of course the right way to handle this, it is > generally best to announce timelines more than two days in advance. > > You're certainly not the only case of this problem - I've noticed a > tendency to post a tracker for some issue, watch nothing happen for > six months, and then see an announcement that the change is being > pushed through in a few days. > > Changes with a big impact should be announced on the lists well before > they are made. > > Also, while users running unstable systems are naturally going to be > at risk for unforeseen issues, this isn't an unforeseen issue. When > we know a problem exists, we generally should fix it before we commit > it. If some uncommon package breaks I think we can live with that, > but gnutls doesn't fall into that category. > > I'm not really interested in the blame game either. This isn't your > problem, or the gnutls maintainer's problem - this is Gentoo's > problem, and I hope we don't make it our user's problem for failure to > work together. I think part of Mike's point is that time and time again has proven that the way to a mans heart^H^H^H^H to get things fixed is to break them. The aforementioned example of a tracker open for months with no progress is an example of halted progress. If we waited to fix all known issues prior to launch, then we would never launch. This is very common in software development. Some features are v2 features, some bugs are not worth fixing. Some bugs we will fix with a patch post-launch; I don't see how this is any different. -A > > Rich >
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Sun, Aug 19, 2012 at 11:07 PM, Mike Frysinger wrote: > On Sunday 19 August 2012 04:41:17 Luca Barbato wrote: >> On 8/18/12 5:31 AM, Mike Frysinger wrote: >> > i'll probably land it later this weekend/monday. >> >> Would be nice having a list of bugs open so people might have a look and >> see if there is something big left. > > we've been making trackers for the glibc upgrades: > https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.16 While trackers are of course the right way to handle this, it is generally best to announce timelines more than two days in advance. You're certainly not the only case of this problem - I've noticed a tendency to post a tracker for some issue, watch nothing happen for six months, and then see an announcement that the change is being pushed through in a few days. Changes with a big impact should be announced on the lists well before they are made. Also, while users running unstable systems are naturally going to be at risk for unforeseen issues, this isn't an unforeseen issue. When we know a problem exists, we generally should fix it before we commit it. If some uncommon package breaks I think we can live with that, but gnutls doesn't fall into that category. I'm not really interested in the blame game either. This isn't your problem, or the gnutls maintainer's problem - this is Gentoo's problem, and I hope we don't make it our user's problem for failure to work together. Rich
