d have
otherwise applied on the non-Free kernel published at kernel.org.
Thanks, and keep up the good work,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler
7;m missing something and
that led me to an incorrect conclusion?
Thanks in advance for any enlightenment you may be able to offer,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
FSFLA Board Member ¡Sé Libre! => h
h Debian's positions and
procedures.
On Oct 25, 2008, Ben Hutchings <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-10-25 at 18:28 -0200, Alexandre Oliva wrote:
>> My understanding is that portions of the Debian system that depend on
>> non-Free Software, in spite of being Free them
On Oct 28, 2008, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> [Alexandre Oliva]
>> Say, if these drivers that require non-Free firmware *were* shipped
>> as separate packages (for whatever reason), would they really belong
>> in main, rather than in contrib?
> Now y
On 28 Oct, 2008, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le mardi 28 octobre 2008 à 14:12 -0200, Alexandre Oliva a écrit :
>> I hope the prevalent interpretation of Debian's rules and policies
>> isn't so lax as to make room for such manipulation as packaging s
this list.
BTW, is this an appropriate forum for seeking enlightenment and
offering suggestions about Debian policies, and how they apply to the
decision at hand? If not, I'd be glad to abide by suggestions of more
appropriate Debian mailing lists.
Thanks in advance,
--
Alexandre Oliva
27;t be done,
when abiding by the two priorities stated in the SC depends on it.
> the bundling is certainly more convenient
... for whom? Are both priorities being well-served by this bundling?
Best,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evan
lace. Say, even a WiFi card soldered to the motherboard
can be "replaced" by a USB WiFi interface.
So, if you consider seriously the introduction of a non-free-firmware
repo, please take the opportunity to introduce a non-DFSG docs repo as
well.
Best,
--
Alexandre Oliva http://w
d my suggestion to prevent having to move
libraries in the first place: creating a libc6-specific directory
right now, instead of installing libraries in /usr/lib and having to
move them into another directory when libc7 should be released.
> However, Alexandre Oliva <[EMAIL PROTECTED]> bri
On Jan 27, 1999, "J.H.M. Dassen" <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote:
>> You might have included my suggestion to prevent having to move libraries
>> in the first place: creating a libc6-specific directory righ
ll
result in their packages *having* to be installed with
--prefix=/usr/local, and even then, they will only work on GNU/Linux.
I want to avoid this situation at all costs.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote:
> On 27 Jan 1999, Alexandre Oliva wrote:
>> > Having libtool default to -rpath is what's causing problems.
>> This is IMHO completely backwards :-)
>> When a program is linked with a shared library, a c
On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote:
> On 27 Jan 1999, Alexandre Oliva wrote:
>> Except that, if you replace the library with an incompatible one, you
>> *are* breaking the contract.
> We don't replace libraries with incompatible ones.
Oh yes
On Jan 27, 1999, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> On 27 Jan 1999, Alexandre Oliva wrote:
>> > Having libtool default to -rpath is what's causing problems.
>>
>> This is IMHO completely backwards :-)
> You know, I seem to remember that the
On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote:
> On 27 Jan 1999, Alexandre Oliva wrote:
> Can you tell -rpath to store the rpath for libmycustomthing.so and
> not for libc.so?
No, but, on some systems (for example, GNU/Linux), it is possible to
hard-code the f
nker *does* understand the problem. And it *does*
> have a solution to it. And -rpath turns it off. So we cannot afford to
> use -rpath.
As I have already pointed out, the solution is not complete, otherwise
you'd not be observing any problem.
--
Alexandre Oliva http://www.dcc.unic
On Jan 27, 1999, Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote:
>> 3) I don't want to regret having introduced a flag that caused as much
>> or more trouble than -rpath; and
> I don't understand
es as it is.
Not in the interface it presents to its users. Internally, it's
obviously full of special cases to support all the crazyness of OS
developers and their wonderful dynamic linkers.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.
it worked well you wouldn't be complaining about a problem that is
caused by its incomplete behavior, but that could be avoided by
modifying other pieces of software that are doing their jobs
correctly.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
tential problems that
I can't foresee.
But I agree, it's a nice feature, and we may be able to adopt it in
the future, on platforms that support it.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
bad because it prevents you from moving shared libraries
> around freely.
It does not. It just prevents you from arbitrarily replacing a
library with an (in)compatible version of it. Since you shouldn't do
that, libtool is not the piece of software to be blamed for using
-rpath.
--
Al
m /usr/lib to
/usr/lib/libc5, you established a rule that, if any program was linked
with libc5, it should look for libraries in /usr/lib/libc5 first,
right? Then why doesn't ld.so follow this rule, by replacing /usr/lib
with /usr/lib/libc5 when it finds this directory in the rpath too?
--
On Jan 29, 1999, Richard Braakman <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> ld.so is trying to outsmart everybody, but it is not smart enough to
>> do it. When you moved libc5-compatible libraries from /usr/lib to
>> /usr/lib/libc5, you established a ru
On Jan 29, 1999, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
>> > Didn't we decide that all of the available alternatives that you have
>> > suggested are not a feasable solution (does this mail help make it clear
>> > why)?
> On 29 Jan 1999, Alexandre
On Jan 29, 1999, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 29, 1999 at 07:11:54AM -0200, Alexandre Oliva wrote:
>> On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote:
>>
>> > Therefore, we chose to solve that particular problem (the libc5-6
On Jan 29, 1999, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote:
>> Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the
>> library search path in certain circumstances? The hack is incomplete,
ou'd just have to modify the libtool script, after it is
generated, so as to set hardcode_libdir_flag_spec to the empty
string. The attached script should do it; just run it after configure
in any Debian package and you're done.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva
e mechanism to do that, we may adopt it.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
spec
2) refrain from hard-coding directories listed in
sys_lib_search_path_spec (but not in $shlibpath_var) in executables
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
* you install it.
Yep, this is a known bug in libtool, and a partial fix for it, by
Edouard Parmelan, is already installed in the CVS tree. Hopefully,
someone will soon be able to complete his work, based on the short
description of what is missing he recently provided.
--
Alexandre Oliva h
v
packages, programs that would run on Devian distributions would not
run in any other, because /dev/lib is not listed in /etc/ld.so.conf,
and libtool had failed to add /dev/lib to the rpath of Devian
programs. Who's to blame for that?
Of course, the solution is easy: adding the directory to ld.so
On Jan 30, 1999, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> On 30 Jan 1999, Alexandre Oliva wrote:
>> I agree there is a problem to be fixed, I just think that libtool
>> is not the only piece of software that may have to be changed to
>> fix it, because it is not
ram.
It is possible, though, to create a shared library with `-soname
/usr/lib/libfoo.so.2', but then it becomes absolutely impossible to
move the library around. There are times when this behavior is
desirable, but libtool never does this, and there is no way to tell
libtool to do it.
On Jan 30, 1999, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> On 30 Jan 1999, Alexandre Oliva wrote:
>> Thanks God I've got only one group of developers almost forcing me to
>> change something that is correct, and whose change wouldn't even help
>> them
btool failed to -rpath /dev/lib, would be that, even if libraries
that are part of Devian packages are properly installed in /dev/lib,
they will not be found by Devian programs, because /dev/lib will not
be searched.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTE
t here is that I have the feeling that I will
> *not* be able to use this marvelous tool that is libtool...
I'm pretty sure we'll be able to work it out :-)
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED]
[EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
gured, it will
not be found (of course :-).
But if an unrelated library with the same soname is installed in the
hard-coded path or in some directory the dynamic linker is configured
to use, the user (or the packager) is asking for trouble, and that's
what he'll get.
--
Alexandre Oliva http
r backward-compatibility with libc5, another for users that have
already upgraded to libc6. You'll have to do it at some time anyway,
when standard distributors stop including libc5 in their default
installations, so why not start doing it now?
--
Alexandre Oliva http://www.dcc.unicamp.br/~o
27;m not
going to accept a patch that drops implicit rpath flags for libraries
listed in ld.so.conf (or just in sys_lib_search_path_spec, for a
start). I'd implement it myself if I were not so much overloaded with
academic issues.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oli
39 matches
Mail list logo
