public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Peter Alfredsen <loki_val@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev]  Re: Please review: function epunt_la_files for eutils.eclass
Date: Sat, 15 Nov 2008 00:05:52 +0100	[thread overview]
Message-ID: <200811150005.54423.loki_val@gentoo.org> (raw)
In-Reply-To: <20081113221413.71edadab@halo.dirtyepic.sk.ca>

[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]

On Friday 14 November 2008, Ryan Hill wrote:
> > [Snip more pie-in-the-sky]
> >
> > Show me the code, please.  
>
> If you weren't interested in hearing differing opinions, then why did
> you ask in the first place? :P

I just thought it sounded like a tall order, saying that fixing 
libtool .la files would take some weekends to do, when this problem has 
existed for so long, yet noone has been able to fix it in a way that 
causes less pain than removal of all .la files does. IOW, I will 
believe promises of code when I see it.

I won't be touching libtool. You can break that thing by just looking at 
it the wrong way. It'll eval your buttocks off and expr your behind, 
it's .3 MB of all posix-sh and it will make you regret you ever tried 
to wrap your head around it.

[in re pulseaudio, I believed the news for 0.9.1 
http://www.pulseaudio.org/wiki/OldNews]

[Responding to the rest of the thread]

I've given this some thought and I think I've been convinced that 
dberkholz' position is probably the most tenable. If this is to be 
done, we should do it in a documented "Gentooish" way. The problem with 
going down the FEATURES road are two-fold:
1) What should the behavior of the FEATURES flag be?

I think it should act like an INSTALL_MASK="*.la" and 
EXTRA_ECONF="--disable-static"

There should also be a function, let's call it "exemptthis.la" that 
would exempt a .la file from being punted, so the RESTRICT could be 
made on a per-la file basis.

2) Who implements in portage?

[...I know nothing of portage internals...]

3) Grunt work?

This should be rather easy. Just assign the bugs to me and I shall add 
RESTRICTs as-needed.

But the problem is that we've known about this for aeons and nothing has 
been done about it. Diego tried to do something with popt and another 
package some time ago (bug 218286) but he was mostly shouted down and 
nobody touched it since.

On .so bumps I've silently dropped .la files, which I think is the more 
gradualistic approach and it also has the advantage of causing only 
little or no (extra) breakage, but for the whole tree it could take 
decades, since some libs don't do .so bumps. 

Anyway, we really need to start punting .la files one way or the other. 
For desktop users of our distro, they do a lot more harm than good. For 
embedded, perhaps static linking serves some purpose, but really, if 
you can't afford dynamic linking, what are you going to run on your 
board?

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2008-11-14 23:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-09 16:04 [gentoo-dev] Please review: function epunt_la_files for eutils.eclass Peter Alfredsen
2008-11-09 16:10 ` Fabian Groffen
2008-11-09 16:34   ` Peter Alfredsen
2008-11-09 16:48     ` Fabian Groffen
2008-11-09 17:46       ` Peter Alfredsen
2008-11-09 17:53         ` Fabian Groffen
2008-11-12 13:41     ` Mart Raudsepp
2008-11-12 14:40       ` Peter Alfredsen
2008-11-12 16:14         ` Rémi Cardona
2008-11-12 17:16           ` Peter Alfredsen
2008-11-13  6:21             ` Donnie Berkholz
2008-11-14 10:35             ` Gilles Dartiguelongue
2008-11-14 17:28               ` Marius Mauch
2008-11-14 14:25             ` Alexis Ballier
2008-11-14 14:35               ` Rémi Cardona
2008-11-16  8:44                 ` Michael Haubenwallner
2008-11-16 22:21                   ` Rémi Cardona
2008-11-14 22:31               ` Donnie Berkholz
2008-11-14 22:33                 ` Ciaran McCreesh
2008-11-14 22:44               ` David Leverton
2008-11-12 16:53         ` Mart Raudsepp
2008-11-12 17:31           ` Peter Alfredsen
2008-11-13 18:49             ` [gentoo-dev] " Ryan Hill
2008-11-14  4:14             ` Ryan Hill
2008-11-14 23:05               ` Peter Alfredsen [this message]
2008-11-14 23:25                 ` Ciaran McCreesh
2008-11-15  0:26                 ` Mart Raudsepp
2008-11-15  6:44                   ` Duncan
2008-11-17 19:19                 ` [gentoo-dev] " Steve Long
2008-11-12 15:52     ` [gentoo-dev] " Donnie Berkholz
2008-11-12 16:24       ` Peter Alfredsen
2008-11-13  6:23         ` Donnie Berkholz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200811150005.54423.loki_val@gentoo.org \
    --to=loki_val@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox