FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-21-2007, 08:35 AM
Raphael Hertzog
 
Default Early adopters of symbol based dependencies needed

On Wed, 21 Nov 2007, Mike Hommey wrote:
> FWIW, I'm testing this on libxml2. I'd have some remarks:
> - The .symbols file in /var/lib/dpkg/info is bigger than all the other
> maintainer files there for libxml2. If a significant amount of packages
> implement this, it can start to make a difference. It might be nice to
> support a gzipped format.

In particular for C++ packages. For C packages, the size impact is quite
limited compared to the size of the respective libraries.

I didn't implement this until now because all files in control.tar.gz have
always been plain text files and I'm not sure I want to change this. Other
opinions are welcome.

> - Python modules have the same problem as perl modules: the interpreter
> doesn't link against the library, so they can't either. That makes a
> whole bunch of warnings for each symbol not found... I'm not sure what
> should be done for that.

Is fixed in git as already noted.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 08:49 AM
Raphael Hertzog
 
Default Early adopters of symbol based dependencies needed

On Wed, 21 Nov 2007, Russ Allbery wrote:
> Be careful about && because you can get the opposite problem.
>
> exists $self->{flags}{DYNAMIC && $self->{flags}{DYNAMIC}
>
> will be parsed as
>
> exists ($self->{flags}{DYNAMIC && $self->{flags}{DYNAMIC})
>
> It's often good style to always use parens with the argument to defined or
> exists because they're most often the functions that get bitten by this.

Aren't they supposed to have a prototype to avoid such behaviour?

I mean exists should behave like myprint2 in the example below:
sub myprint {
print $_[0] . "
";
}

sub myprint2 ($) {
print $_[0] . "
";
}

%a = ('a' => 'this is a');
myprint $a{a} && exists $a{a};
myprint2 $a{a} && exists $a{a};

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 09:56 AM
Russ Allbery
 
Default Early adopters of symbol based dependencies needed

Raphael Hertzog <hertzog@debian.org> writes:

> Aren't they supposed to have a prototype to avoid such behaviour?

Ah, indeed. I had forgotten about that. You're entirely correct.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 12:13 PM
Florian Weimer
 
Default Early adopters of symbol based dependencies needed

* Russ Allbery:

>> As I understand it, this is only the case on i386 - on other arches,
>> /usr/bin/perl links to libperl, although the modules don't.
>
> ...indeed. That's bizarre. Why is i386 different than all the other
> platforms?

Performance penalty of PIC code due to register pressure, I guess.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 12:19 PM
Stephen Gran
 
Default Early adopters of symbol based dependencies needed

This one time, at band camp, Florian Weimer said:
> * Russ Allbery:
>
> >> As I understand it, this is only the case on i386 - on other arches,
> >> /usr/bin/perl links to libperl, although the modules don't.
> >
> > ...indeed. That's bizarre. Why is i386 different than all the other
> > platforms?
>
> Performance penalty of PIC code due to register pressure, I guess.

Is this a significant enough issue to live with the other issues this
creates? I honestly don't know. It 'feels' like the right way to have
perl compiled would be the same on all architectures, /usr/bin/perl
linked to libperl, and the binary modules linked to libperl. I
understand this may be a problem, I just don't know how big of one it
would be.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 11-21-2007, 03:01 PM
Joey Hess
 
Default Early adopters of symbol based dependencies needed

Raphael Hertzog wrote:
> Given that shlibs are still used as fallback, I don't see a reason to
> remove -V, in particular given that unofficial archs might not have
> symbols files when they are arch-specific and when something specific
> needs to be done to add support for a new arch.

I thought that part of the point of the symbols files was to get more
accurate dependency information. If unversioned -V is used, dependencies
will remain overly tight.

--
see shy jo
 
Old 11-21-2007, 03:02 PM
Joey Hess
 
Default Early adopters of symbol based dependencies needed

Florian Weimer wrote:
> * Russ Allbery:
>
> >> As I understand it, this is only the case on i386 - on other arches,
> >> /usr/bin/perl links to libperl, although the modules don't.
> >
> > ...indeed. That's bizarre. Why is i386 different than all the other
> > platforms?
>
> Performance penalty of PIC code due to register pressure, I guess.

I seem to remember it was a threading issue, but I didn't manage to
track down an explanation.

--
see shy jo
 
Old 11-21-2007, 04:00 PM
Raphael Hertzog
 
Default Early adopters of symbol based dependencies needed

On Wed, 21 Nov 2007, Joey Hess wrote:
> Raphael Hertzog wrote:
> > Given that shlibs are still used as fallback, I don't see a reason to
> > remove -V, in particular given that unofficial archs might not have
> > symbols files when they are arch-specific and when something specific
> > needs to be done to add support for a new arch.
>
> I thought that part of the point of the symbols files was to get more
> accurate dependency information. If unversioned -V is used, dependencies
> will remain overly tight.

But -V affects only what's in shlibs file, no? And shlibs files are
ignored if dpkg-shlibdeps is able to find symbols files. So it doesn't
change the resulting dependency for architectures where we have symbols
files.

And it makes a safe fallback (even with overly tight dependencies). But
this is not a serious concern for unofficial architectures until they are
officially supported. And it also doesn't concern packages where the
set of symbols is the same across all architectures.

So it's not a big deal in the end.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 04:16 PM
Mike Hommey
 
Default Early adopters of symbol based dependencies needed

On Wed, Nov 21, 2007 at 10:35:50AM +0100, Raphael Hertzog wrote:
> On Wed, 21 Nov 2007, Mike Hommey wrote:
> > FWIW, I'm testing this on libxml2. I'd have some remarks:
> > - The .symbols file in /var/lib/dpkg/info is bigger than all the other
> > maintainer files there for libxml2. If a significant amount of packages
> > implement this, it can start to make a difference. It might be nice to
> > support a gzipped format.
>
> In particular for C++ packages. For C packages, the size impact is quite
> limited compared to the size of the respective libraries.
>
> I didn't implement this until now because all files in control.tar.gz have
> always been plain text files and I'm not sure I want to change this. Other
> opinions are welcome.

Maybe that should be done when dpkg puts the files in
/var/lib/dpkg/info, not in control.tar.gz

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2007, 09:38 PM
Joey Hess
 
Default Early adopters of symbol based dependencies needed

Raphael Hertzog wrote:
> And shlibs files are ignored if dpkg-shlibdeps is able to find
> symbols files.

Ah, that wasn't clear, I must have missed that in the documentation.

--
see shy jo
 

Thread Tools




All times are GMT. The time now is 12:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org