[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140610094351.GE20596@example.net>
Date: Tue, 10 Jun 2014 11:43:51 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: Re: musl 1.0.x branch
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
