Hi, Alexander and Fabian (and Alexandre and Gerfried on CC).
On Jun 11 2008, Alexander Leidinger wrote:
> Quoting Fabian Greffrath <
[hidden email]> (from Wed, 11 Jun
> 2008 10:36:50 +0200):
> > Alexander Leidinger schrieb:
> > Dont' get me wrong, we do this in good faith and not because we have
> > too much time to spend on rebuilding tarballs. The main reasons are
> > (1) the overall bad quality of many of the provided debian/
> > directories (this is not directly against LAME, but the one in e.g.
> > libquicktime has not been maintained since ~2004) and (2) because we
>
> Do you also have an example of a tarball with a well maintained debian
> directory?
I am a maintainer of other 3 Debian packages that *are* in the official
repository. Even though I am mostly the only one who changed the debian
directory for lame (which may mean that I am biased myself), I think
that the job that I've done isn't bad. I have updated the packaging with
the most recent Debian policy (well, actually, one has *just* been
released, but I think that almost no changes (or little ones, at most)
would be needed to be on the bleeding edge of things).
And you should have a shining Debian package. I have even actively hunt
and incorporated changes of the most widely distributed binary package
for lame (which is Christian Marillat's from www.debian-multimedia.org)
and chose which ones are worth keeping and I think that, in some
respects, my package is better than his (for instance, the name of the
library package is actually libmp3lame0, *not* liblame0), but I provide
a dummy package so that what people get is a drop-in replacement for his
package.
> Basically that's what we offer, incorporating patches to make the
> debian directory well maintained. Based upon my experience on FreeBSD
> (I'm a FreeBSD developer in the past I had some packages with
> extensive FreeBSD specific changes): as less changes you have to do
> locally (for "your own" package management system), the better.
No questions about that. And changes should always be offered upstream.
> If you have a package where the upstream author (in this case we, the
> LAME authors) are listening to the needs of the package maintainer,
> then it is great, push as much local stuff upstream (in a way which
> doesn't hurt other platforms) and you have less work to do during
> updates.
ACK.
> > It's not a Debian-related problem. It occurs whenever you try to link
> > against libmp3lame with '-Wl,--as-needed' to avoid unecessary
> > dependencies.
>
> Ok, let's use a different description: I'm wondering why libm is not
> automatically added to the frontend ldflags already.
>
> Hmmm... in configure.in we have
> FRONTEND_LDADD="${FRONTEND_LDADD} ${CONFIG_MATH_LIB}"
> which should already contain -lm.
>
> Is lame compiled with libsoundfile on debian?
The package that I provide in our own repository is. This was the saga
where I kept asking you to see the auto* stuff, so that the package
today works AT LEAST with the following 3 architectures under Debian:
i386 (ia32), x86-64, and powerpc. I have fed .flac compressed files
(which lame gets via libsndfile) (as well as ordinary .wav) to lame and
the result was superb.
It also builds fine on MacOS X (on ia32). I still have not installed the
Apple developer tools on my MacOS X on PowerPC. So, as you can see, I
can test lame on 5 different environments.
> Have you tried to move the sndfile libs in front of the frontend
> ldflags stuff?
I didn't have to do that with the package we create: I just selected,
during the configure phase, the option saying that I want libsndfile and
have the development things of libsndfile1 installed on the Debian
system.
BTW, the current tarball that is released (3.97) doesn't have all the
goodness that CVS HEAD has (like libsndfile support, fractional VBR
quality setting, much improved encoding---even on arches that don't have
asm coded computationally intensive routines, like powerpc).
> > Nowadays most unixoid systems should provide a package management that
> > can handle dependencies properly, so I see no reason in installing the
> > same library code in three binaries on one system. If you want to
>
> BTW: the only executable a lame package should install is lame itself.
The way that I packaged lame on our repository creates 4 different
packages (sorry for not communicating this before, but I think that you
guys would be bored with long descriptions of that):
* the lame package, which, indeed, only contains the lame executable and
copyright files and other similar things required by Debian;
* the libmp3lame0 package, which is a dynamically library on which other
packages can depend (like, say, ffmpeg or mencoder);
* the libmp3lame0-dev package, which contains the header files needed
for compiling things with lame;
* the liblame0 to fulfill the gap for people whose installation uses
Marillat's repository.
> The mp3x is a pure developer program, if you don't want to modify the
> lame mp3 algorithms, this program is completely useless for you (and
> you can get rid of the gtk1 and x11-lib dependency completely). If you
> want to modify the mp3 algorithms, you should use the CVS version of
> lame anyway.
Yes, I thought about packaging these, but Debian has since phased out
gtk1 from the current versions of the repository (everything has to
compile with gtk2 or other modern graphical toolkit).
> The mp3rtp one is not really maintained and there is other software
> which is better suited, e.g. icecast or shoutcast or something like
> this. mp3rtp is more a development tool for rare use cases than really
> something which should be used in production.
Again, not packaged.
> > manually move the tools between two systems, copy the library as well
> > and you're done. ;)
>
> This does not work for unix-beginners, they don't know about
> LD_LIBRARY_PATH or may have root access.
Not only that, but you have to have shared libraries that work with the
libc installed on the new system, which we can't guarantee. I think that
the audacity sound editor relies, on Mac systems, on having a shared
object that is callable to export your sound project to MP3.
> Again: personally I don't object to the change, I'm all for your
> proposal to remove the -static switch. I agree on the dependency
> tracking part of package management systems.
Couldn't we leave this static linking in for the default builds from the
project and leave this minor thing for packagers? I don't know how Red
Hat systems work here regarding package dependencies (they used to have
*file* dependencies instead of package dependencies and that's the last
time when I touched one of these systems).
OTOH, if there is realy a desire to remove -static, I can test our
packaging and see if we improve on things.
But, in principle, I'm all for a minimal system.
Regards, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito :
http://meusite.mackenzie.com.br/rbritoProjects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
