Re: (not) simplifying dpkg-shlibdeps with readelf

2010-04-28 Thread Hector Oron
Hello Russ,

2010/4/27 Russ Allbery :
> I have a hard time imagining Debian ever supporting non-ELF targets.  We'd
> need to maintain a completely separate libc, for instance, since I'm
> fairly sure glibc is ELF only.

uClibc is on the archive (not usable for runtime), it was also added
to dpkg as a new architecture, maybe someday we'll have a uClibc (w/
MMU and w/o MMU).
We might need to support flat binaries for that.

There are also some teams and individuals which have the desire to
work on mobile world having Debian on them, for such purposes and
maybe not officially, there is space for a bionic libc or some others
that might be suitable for such purposes.

I do not want to interfere on the decission of using readelf, but at
least take into account those points before doing any change which
might be hard to revert later on.

Kind regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."


--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/h2tdd0a3d701004280404u265efd3ai4d61b25d91589...@mail.gmail.com



Re: (not) simplifying dpkg-shlibdeps with readelf

2010-04-28 Thread Russ Allbery
Hector Oron  writes:
> 2010/4/27 Russ Allbery :

>> I have a hard time imagining Debian ever supporting non-ELF
>> targets.  We'd need to maintain a completely separate libc, for
>> instance, since I'm fairly sure glibc is ELF only.

> uClibc is on the archive (not usable for runtime), it was also added
> to dpkg as a new architecture, maybe someday we'll have a uClibc (w/
> MMU and w/o MMU).

I'm fairly sure that uClibc is ELF.

> We might need to support flat binaries for that.

I'm not sure what you mean by "flat binaries" here.  ELF versus non-ELF is
a much more fundamental distinction than, say, whether or not something is
dynamically linked.  I don't believe the Linux kernel will even run
non-ELF binaries without special module support.

> There are also some teams and individuals which have the desire to
> work on mobile world having Debian on them, for such purposes and
> maybe not officially, there is space for a bionic libc or some others
> that might be suitable for such purposes.

I see no reason why embedded platforms can't use ELF.  ELF is very common
in the embedded world even entirely apart from Linux.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bpd3tm1z@windlord.stanford.edu



Re: Indentation in package descriptions

2010-04-28 Thread Christian PERRIER
Quoting Martin Eberhard Schauer (martin.e.scha...@gmx.de):
> Recently some  descriptions  added a space character in the second and the
> following lines of a paragraph, they changed their format from
> foo
> bar
> blurb
> 
> to
> foo
>  bar
>  blurb.
> 
> One more space character is meant for the display of lists, and normal text
> looks quite ugly. One example is
> 
> http://packages.debian.org/sid/postfix-cdb.

this one comes from the postfix package, that has a special way to
deal with its control file.

In the package source tree, the control file looks like this:

Package: postfix-cdb
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, postfix (= ${binary:Version})
Description: CDB map support for Postfix
 ${Description}
 .
 This provides support for CDB (constant database) maps in Postfix. If you
 plan to use CDB maps with Postfix, you need this.

the source tree also has debian/vars.in:

Description=Postfix is Wietse Venema's mail transport agent that started life 
as an${Newline} alternative to the widely-used Sendmail program.
  Postfix attempts to${Newline} be fast, easy to administer, and secure, while 
at the same time being${Newline} sendmail compatible enough to
not upset existing users. Thus, the outside${Newline} has a sendmail-ish 
flavor, but the inside is completely different.


vars.in is added, at build time to debian/substvars. This is used by
deb-substvars(5). From this package's manpage:

   Additionally, the following standard variables are available:
.../...
  Newline, Space, Tab
  These variables each hold the corresponding character.


The problem, here, is that, apparently ${Newline} gets expanded 
to "\n " and not "\n".

So, if there's a bug, it is in dpkg





signature.asc
Description: Digital signature


Re: Indentation in package descriptions

2010-04-28 Thread Raphael Hertzog
On Thu, 29 Apr 2010, Christian PERRIER wrote:
> Description: CDB map support for Postfix
>  ${Description}
>  .
>  This provides support for CDB (constant database) maps in Postfix. If you
>  plan to use CDB maps with Postfix, you need this.
> 
> the source tree also has debian/vars.in:
> 
> Description=Postfix is Wietse Venema's mail transport agent that started life 
> as an${Newline} alternative to the widely-used Sendmail program.
>   Postfix attempts to${Newline} be fast, easy to administer, and secure, 
> while at the same time being${Newline} sendmail compatible enough to
> not upset existing users. Thus, the outside${Newline} has a sendmail-ish 
> flavor, but the inside is completely different.
> 
[...]
> The problem, here, is that, apparently ${Newline} gets expanded 
> to "\n " and not "\n".

${Newline} gets expanded to "\n" but the substvar substitution is
done on the content of the field after it has been parsed and not before
which means that you don't get to see/deal with the initial space any
more.

This was probably different in older version of dpkg-dev but it has never
been codified one way or another. The current approach is cleaner as you
can put any value in the substvar and it should work. Before if you forgot
the space you would have generated something invalid...

This was changed in dpkg-dev 1.15.5. I would suggest to fix postfix
to match the new behaviour (and build-depend on dpkg-dev (>= 1.15.5)
to avoid problems with older dpkg-dev).

I just added a paragraph in deb-substvars(5) to document this behaviour.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100429062120.gb3...@rivendell