Bug#813097: RFA: libowfat -- reimplementation of libdjb

[stigge]

Package: wnpp
Severity: normal

I'm not using this package regularly. Looking for a new maintainer.

Re: Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))

[Guus Sliepen]

On Thu, Jan 28, 2016 at 01:38:11PM +, Ian Jackson wrote:

> Static libraries are useful to users who want to build binaries and
> then ship them about without all the library clobber. [...]
> 
> Overall I do think the costs of providing the static libraries, even
> where a shared library is also provided, are justifiable.

I agree with this. But what I don't understand is why, if the loader can
link an executable with shared libraries at run-time, the compiler can't
link those same shared libraries *into* the executable at compile time.
Is there a technical reason or is it just because "that's how it's
always been done"?

(I know there are tools to create a single executable from a dynamically
linked executable + the .so files it depends on, like
http:/statifier.sf.net, but they are kind of an ugly hack.)

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))

[Dimitri John Ledkov]

Hello,

On 28 January 2016 at 14:38, Ian Jackson
 wrote:
> Andreas Tille writes ("Statically linked library in libdevel packages? (Was: 
> Status of teem package (packaging moved from svn to git))"):
>> I came across this question since policy says (see link above) that
>> static libraries are *usually* provided.  I do not question Mattia's
>> arguing but if his opinion might reflect a consensus the wording in
>> policy is IMHO wrong.
>>
>> I stumbled upon the missing static library since d-shlibmove (from
>> d-shlibs package) is requiring this static library (since d-shlibs
>> is implementing library policy).  So if there is some consensus to
>> drop the static library I'd file a bug report against d-shlibs.
>
> Static libraries are useful to users who want to build binaries and
> then ship them about without all the library clobber.  I don't know
> how much that happens but when it does happen it's probably people who
> are already having some kind of problem.
>

People who build and ship binaries & libraries, do so by building a
docker container and shipping it to docker hub.
And/or any other similar chroot-based deployment solutions are near
enough to that.
(python virtualenvs, go vendorisation, ruby bundler deploy, etc)

because static binaries do not work, e.g. nss does not work, etc.

> Overall I do think the costs of providing the static libraries, even
> where a shared library is also provided, are justifiable.
>

It's an upgrade and security trap. Yeap, upgraded ssl, restarted all
service, but haha not the statically linked ssl one.

Also, on the bring up of new architectures (and/or code bitrot) I have
seen shared libraries no longer detected (e.g. present but cannot be
compiled) and configury falling back to static linking when it was not
intended to.

Imho, if static libraries, are shipped we should be conservative about
them (e.g. do it pretty much for libc only to compile minimal
freestanding bootloaders and that's about it).

Or for example do split them into a separate link path, or separate
package - since it would also require Built-Using stanzas. If one
build-depends on static library package, and doesn't generate
Built-Using something fishy is going on.

Anything leaf, or beyond minimal/core libraries, really has no need
for static libraries. And definitely none of the TLS or crypto
libraries.

-- 
Regards,

Dimitri.

Bug#813147: ITP: emcee -- Kick ass affine-invariant ensemble MCMC sampling for Python

[Ole Streicher]

Package: wnpp
Owner: Ole Streicher 
Severity: wishlist
X-Debbugs-Cc: 
debian-devel@lists.debian.org,debian-as...@lists.debian.org,debian-pyt...@lists.debian.org

* Package name: emcee
  Version : 2.1.0
  Upstream Author : Dan Foreman-Mackey 
* URL : http://dan.iel.fm/emcee/
* License : MIT
  Programming Lang: Python
  Description :  Kick ass affine-invariant ensemble MCMC sampling for Python
 emcee is an extensible, pure-Python implementation of Goodman &
 Weare's Affine Invariant Markov chain Monte Carlo (MCMC) Ensemble
 sampler. It's designed for Bayesian parameter estimation.

This package will maintained within the Debian Astronomy Working Group.
A git repository will be created on alioth [1].

Best regards

Ole

[1] https://anonscm.debian.org/cgit/debian-astro/packages/emcee.git

Re: Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jan 29, 2016 at 06:03:26PM +0100, Dimitri John Ledkov wrote:
> Imho, if static libraries, are shipped we should be conservative about
> them (e.g. do it pretty much for libc only to compile minimal
> freestanding bootloaders and that's about it).
> 
> Or for example do split them into a separate link path, or separate
> package - since it would also require Built-Using stanzas. If one
> build-depends on static library package, and doesn't generate
> Built-Using something fishy is going on.
> 
> Anything leaf, or beyond minimal/core libraries, really has no need
> for static libraries. And definitely none of the TLS or crypto
> libraries.

We all agree that Debian packages should only use static libraries in
exceptional situations; a Linian check against using them would be useful (and
perhaps it already exists?)  The exceptional situations can use overrides.

But that doesn't mean we should prevent our users from using them.  Some want
to, and they have their reasons for it.  We should explain that shared
libraries are better in most cases, but if they aren't convinced, we should let
them do what they want.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWrCXyAAoJEJzRfVgHwHE6RRAQAJmUZnP7vU0J9Le9En8LWt3B
6cCtoKgbxRJlkLwjk2XE6Y5SZGblVBtNn4XgrrDCf2wz3QhbW6SQNfP+V77afG1l
QwgIYVT5gCnIXyY9E+keyUb8NKOO1IAI82NQJ4MnVFy80peqeHL2Yqj0GloFWv1x
xawoCJ2htX+lPXilXgqs87W9ZD3CpM9FzBAVxIrVy7Q7uecPgy19cK2SG9l+R1R/
eLD4OEgczOeI0wLdu9oQSm+/a5Jl07nFB7ABojBMVK23eYiXEqRTzsFxirHXJGyM
uygE6V7dlM0HT2IGAd9EGFg11x7SGrw+6Cfbg1tDXhBTAozGNYUgLJm9cGijxm8x
N22O4iclPjcc4JV/gwnycC3vD8Xs62qiq9jd2HL8JbnHd8w277OD/dhyBKUlAnSo
zJObXI7rQIyD1RAwe9pteir0edgVzbWaJJEXvmQAkj+jKGsKMw6586ZejWMombcm
6iTdUsmwQmlf5z5GnZ/VCJTkDI6d6+jf1tKoG3A93z1dPvE4m8lvJyzcmcsEnvhN
KP2LX77OPGo0DNpYuj9gaPtdhGGO3hRJnpjBVGZpjh8uXLiArUTGOVlb606w3/WK
cdYwKOkKrC3qlbtq5QiAyGm1fRXyG4DMfbyi5svWC9g5Ms+b5i2OyKAR3OM9Gnoo
YRuOmAuamUx3hmLU9S2n
=2S42
-END PGP SIGNATURE-