From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5215 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 1.0.x branch Date: Tue, 10 Jun 2014 11:43:51 +0200 Message-ID: <20140610094351.GE20596@example.net> References: <20140606175617.GA3914@brightrain.aerifal.cx> <20140609112352.1e7ad51e@ncopa-desktop.alpinelinux.org> <20140609200830.GK179@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1402393506 1165 80.91.229.3 (10 Jun 2014 09:45:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Jun 2014 09:45:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5220-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 10 11:45:00 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WuIbv-0005NC-7o for gllmg-musl@plane.gmane.org; Tue, 10 Jun 2014 11:44:55 +0200 Original-Received: (qmail 19689 invoked by uid 550); 10 Jun 2014 09:44:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19675 invoked from network); 10 Jun 2014 09:44:52 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe04.swip.net; client-ip=178.217.187.39; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140609200830.GK179@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5215 Archived-At: On Mon, Jun 09, 2014 at 04:08:30PM -0400, Rich Felker wrote: > Having a rolling > "well-tested and believed stable except for known bugs X, Y, and Z" > release that's a few versions behind the latest release, and a list of > commits since then which are purely bug-fixes, might be a good > practical option. Such pairs of (base-version,list-of-commits) could > automatically be transformed into tarballs. This looks good and makes sense. Despite not having other maintenance-related thresholds we maintain some local patches and it is easier to apply them when the changes inside the codebase are limited. Slightly offtopic: Of course an even better solution would be to have a somewhat stable "interface" for applying changes important to us. We do not use setuid applications (considering them harmful for a number of reasons). This makes it possible and quite desirable to be able to control certain properties of the library at run time. We let a deployment administrator choose e.g. which name services and authentication means are to be used for a certain instance of the application - using environment variables pointing to dedicated hosts/resolv.conf/passwd/group/shadow/pam.d and similar. So if musl would have any kind of hooks to implement this (as a compilation option or say by a convention which would make it easier to apply patches without rereading/rechecking all the source) it would be highly valuable. I understand that this is unconventional and do not expect much of attention but at least it is worth to name that such a need exists. Another change we opted to do is switching off any and all rpath interpretation, which corresponds to our software maintenance routines and makes it easier and safer for us. The less constraints are hardwired, the better we can use the software. (Of course these changes are totally incompatible with the traditional usage of a "general purpose C library" which is shared between both non-setuid and setuid applications. To the contrary, different kinds of applications here get different kinds of the library/ies so that we would not be stuck even if we discover that we badly need setuid in a certain case) Thanks, Rune