Re: [gentoo-dev] Version Bumps
On Sat, 28 Mar 2015 12:16:30 +0100 "Justin Lecher (jlec)" wrote: > Please check packages more carefully e.g. comparing configure.ac, > Makefile.am, README, INSTALL, setup.py, requirements.txt and what all > those names are. Also make sure your CApitalisation in ChangeLog MEssages is COrrect. jlec → gentoo-x86 (sci-biology/allpathslg/) Version BUmp; move to EAPI=5 and autotools-utils.eclass; thanks Martin Mokrejs for preparing the bump jlec → gentoo-x86 (net-analyzer/ospd/) Version BUmp; Drop py3 support, bug #530992 jer
Re: [gentoo-dev] Should Gentoo do https by default?
On Mon, Mar 30, 2015 at 8:58 PM, Dean Stephens wrote: > On 03/27/15 15:29, Hanno Böck wrote: > > These days pretty much all big players use https only (google, > > facebook, twitter, github, ...). You can't really use the > > mainstream internet if your firewall blocks https. > > > Can we please stop making stuff up[1] just to make an argument seem > stronger to the overly credulous? I agree his argument is bogus (plenty of the internet is http) but relying on undocumented query arguments to prevent ssl redirection is...not really the example I'd chose to use to illustrate the point. > [1] http://www.google.com/search?q=this+is+not+impossible&gws_rd=ssl
Re: [gentoo-dev] Policy regarding enablement of drop-in configuration files
On Tue, Mar 31, 2015 at 8:36 PM, Alec Warner wrote: > Personally I'm with Vapier that this is a Bad Idea(TM) for the reasons he > stated; but I'm unsure we have "A Policy Against It" > > It seems like something one might offer an eselect module for though. I've had a couple people recommend this; I suppose it's a reasonable alternative. I shall add it to my list of options on the the bug. ^_^
Re: [gentoo-dev] Policy regarding enablement of drop-in configuration files
On Tue, Mar 31, 2015 at 5:14 PM, Mike Gilbert wrote: > On Tue, Mar 31, 2015 at 5:21 PM, Alec Warner wrote: > > > > > > On Tue, Mar 31, 2015 at 11:14 AM, Mike Gilbert > wrote: > >> > >> Hi all, > >> > >> I have been bumping heads with Mike Frysinger (vapier) on the topic of > >> drop-in config files that are utilized by quite a few system services > >> on Gentoo. For reference, see bug 544150. > > > > > > I am going to the movies with Mike tomorrow, I will be sure to cuddle > him on > > your behalf. > > Thanks? ^_^ > Free cuddles for everyone! > > >> > >> > >> Mike claims that Gentoo has a policy of "not enabling anything by > >> default", and that this policy applies to both init scripts, and > >> drop-in configuration files. > > > > > > I would say the policy for *services* is that non-critical services are > not > > enabled by default. I would argue that is a policy decision that is > distro > > wide. > > Maintainers are of course, at liberty to determine if their service is > > 'critical' or not. > > Right, I agree that this makes sense for services. > > But I don't really think the configuration fragments I am referring to > could really be called "services". However, they do affect the > operation of services. > > Should packages be allow to set/alter the configuration of a system > service automatically? I would say yes, and it is up to the maintainer > to decide what is reasonable here. > Personally I'm with Vapier that this is a Bad Idea(TM) for the reasons he stated; but I'm unsure we have "A Policy Against It" It seems like something one might offer an eselect module for though. > > >> My questions to the community: > >> > >> - Do we have a policy regarding enablement of drop-in config files? > > > > > > Maintainers discretion. > > > >> > >> - If so, what is it? Where is it documented? > > > > > > My brain; seriously though, generally undocumented things imply > maintainers > > discretion. > > We either have a policy that the maintainer is supposed to follow > (barring some reasonable exception), or we don't have a policy and the > maintainer can do what they want. > > In the referenced bug, I'm being told that an existing policy applies > here and that a bunch of existing packages violate this policy; I'm > trying to verify if that is the case, and if so, what is the policy, > and how is it applicable? > I think that is a question for Mike, if he can't reference a written policy; he is probably SOL :) -A
Re: [gentoo-dev] Policy regarding enablement of drop-in configuration files
On Tue, Mar 31, 2015 at 5:21 PM, Alec Warner wrote: > > > On Tue, Mar 31, 2015 at 11:14 AM, Mike Gilbert wrote: >> >> Hi all, >> >> I have been bumping heads with Mike Frysinger (vapier) on the topic of >> drop-in config files that are utilized by quite a few system services >> on Gentoo. For reference, see bug 544150. > > > I am going to the movies with Mike tomorrow, I will be sure to cuddle him on > your behalf. Thanks? ^_^ >> >> >> Mike claims that Gentoo has a policy of "not enabling anything by >> default", and that this policy applies to both init scripts, and >> drop-in configuration files. > > > I would say the policy for *services* is that non-critical services are not > enabled by default. I would argue that is a policy decision that is distro > wide. > Maintainers are of course, at liberty to determine if their service is > 'critical' or not. Right, I agree that this makes sense for services. But I don't really think the configuration fragments I am referring to could really be called "services". However, they do affect the operation of services. Should packages be allow to set/alter the configuration of a system service automatically? I would say yes, and it is up to the maintainer to decide what is reasonable here. >> My questions to the community: >> >> - Do we have a policy regarding enablement of drop-in config files? > > > Maintainers discretion. > >> >> - If so, what is it? Where is it documented? > > > My brain; seriously though, generally undocumented things imply maintainers > discretion. We either have a policy that the maintainer is supposed to follow (barring some reasonable exception), or we don't have a policy and the maintainer can do what they want. In the referenced bug, I'm being told that an existing policy applies here and that a bunch of existing packages violate this policy; I'm trying to verify if that is the case, and if so, what is the policy, and how is it applicable?
[gentoo-dev] Re: RFC: app-eselect category
> On Mon, 30 Mar 2015, I wrote: > Since I've seen only favourable replies, I'm going to create the > category on Wednesday. I'll also take care of the package moves and > of reverse dependencies. All done, one day early. Unfortunately, updating reverse dependencies took me longer than expected (repoman and cvs taking their time) so there was some time window with new packages already in place but package moves for the old ones still missing. My apologies to developers and users for any trouble caused by this. In retrospect, I should have asked infra to suspend rsync during the move process. Ulrich pgpj7UrUUsoWQ.pgp Description: PGP signature
Re: [gentoo-dev] Policy regarding enablement of drop-in configuration files
On Tue, Mar 31, 2015 at 11:14 AM, Mike Gilbert wrote: > Hi all, > > I have been bumping heads with Mike Frysinger (vapier) on the topic of > drop-in config files that are utilized by quite a few system services > on Gentoo. For reference, see bug 544150. > I am going to the movies with Mike tomorrow, I will be sure to cuddle him on your behalf. > > Mike claims that Gentoo has a policy of "not enabling anything by > default", and that this policy applies to both init scripts, and > drop-in configuration files. > I would say the policy for *services* is that non-critical services are not enabled by default. I would argue that is a policy decision that is distro wide. Maintainers are of course, at liberty to determine if their service is 'critical' or not. > > I counter that we have no such policy. We don't generally enable init > scripts by default because that just makes logical sense. Mike F. is > trying to apply this same logic to drop-in configs, and that just > doesn't fit. > Regarding drop-in configuration files, there are many examples where > these are generally enabled by default, or it is left to the > maintainers discretion: > > - udev rules are enabled by default > - crontab entries are left to the maintainer, but are generally > enabled by default > - tmpfiles.d entries are enabled by default > - logrotate entries are enabled by default > - binfmt.d entries are enabled by default > > Further, the way many of these services is designed does not allow for > the drop-in configs to be easily disabled by default by the OS vendor. > However, in most cases, they may be disabled by the sysadmin by use of > an overriding drop-in config somewhere under /etc. > > My questions to the community: > > - Do we have a policy regarding enablement of drop-in config files? > Maintainers discretion. > - If so, what is it? Where is it documented? > My brain; seriously though, generally undocumented things imply maintainers discretion. > - If not, do we need a policy and what should it be? > I hope not; but if you do something silly, be prepared to get called on it. > - Keep in mind that any policy needs to be technically feasible to > implement.
Re: [gentoo-dev] Policy regarding enablement of drop-in configuration files
On Tue, Mar 31, 2015 at 2:14 PM, Mike Gilbert wrote: > > - Do we have a policy regarding enablement of drop-in config files? > - If so, what is it? Where is it documented? > - If not, do we need a policy and what should it be? > - Keep in mind that any policy needs to be technically feasible to implement. > I have no idea if one is documented, but I think the best we're going to do is set up some principles (the usual Gentoo stuff) and leave it to maintainer discretion. I don't see how anything else will ever work. For example, you point out that we generally don't enable init.d scripts, but that isn't true for a lot of the stuff that is needed to boot the system. Maybe we don't enable lvm by default, but stuff like procfs or sysctl is always on out of the box, and it just wouldn't make sense not to do it that way (this isn't Linux From Scratch). Of course, we should always allow users to override the defaults either way, enabling stuff or disabling stuff as they please. If one way of setting things up makes it easier for users to tweak things then that should be a consideration. So should be aligning with upstream. Basically, policy shouldn't be an excuse for doing something dumb. -- Rich
[gentoo-dev] Policy regarding enablement of drop-in configuration files
Hi all, I have been bumping heads with Mike Frysinger (vapier) on the topic of drop-in config files that are utilized by quite a few system services on Gentoo. For reference, see bug 544150. Mike claims that Gentoo has a policy of "not enabling anything by default", and that this policy applies to both init scripts, and drop-in configuration files. I counter that we have no such policy. We don't generally enable init scripts by default because that just makes logical sense. Mike F. is trying to apply this same logic to drop-in configs, and that just doesn't fit. Regarding drop-in configuration files, there are many examples where these are generally enabled by default, or it is left to the maintainers discretion: - udev rules are enabled by default - crontab entries are left to the maintainer, but are generally enabled by default - tmpfiles.d entries are enabled by default - logrotate entries are enabled by default - binfmt.d entries are enabled by default Further, the way many of these services is designed does not allow for the drop-in configs to be easily disabled by default by the OS vendor. However, in most cases, they may be disabled by the sysadmin by use of an overriding drop-in config somewhere under /etc. My questions to the community: - Do we have a policy regarding enablement of drop-in config files? - If so, what is it? Where is it documented? - If not, do we need a policy and what should it be? - Keep in mind that any policy needs to be technically feasible to implement.
Re: 回复：Re: [gentoo-dev] RFC News item: FFmpeg default
Nicol TAO wrote: > so. believe it or not? Communication should reduce confusion, not risk increasing it. //Peter
