[xine-devel] Re: xine inclusion in Debian (fwd)

[Siggi L. <lan...@fa...>]

Hi Robert,

On Fri, 15 Dec 2000, Robert van der Meulen wrote:

> > [advantages of native package]
> > - Debian packages are always up to date, as they're released with upstream
> I tend to keep my packages up to date ;)
> Integrating the debian package in your upstream version has advantages, but
> some disadvantages as well; you need to keep your latest xine version
> 'debian-compatable' - also see the remark about libraries, below.

I can't see a problem with this, as I'm actually developing and testing
xine on several Debian machines, sometimes especially taking care of
Debian "specific" stuff. This way, we have come to write a man page, put
the docs into proper directories, fixed some strange permissions and
generally fixed a lot of things. Most of them were of great use for other
distributions (or even OSes like FreeBSD) as well. I don't like the idea
to put them in an external diff, which means that most other developers
won't see them...

> Having a debian-native package would be nice, but probably not handy for
> anything that's not debian-specific.

I don't understand you here. What are the things that are "not
debian-specific" and why would a debian-native package be not handy for
those?

> > The only problem about that is that I'm not a Debian Maintainer yet. I
> > don't know how long that will take, but I'm willing to become one...  I
> > think I've read all the relevant documentation. I'm just lacking someone
> > to approve my gpg key and probably some other adminitrative stuff.  Maybe,
> > you could help me with that?
> My 'new-maintainer' process took quite a while (about 6 months). I don't
> know what the 'status' of the queue is right now, so i really can't say how
> long it would take you to become a maintainer.
> I can sign your gpg key, but i only do that after physically meeting the
> person whose key i sign, and verifying their identity trough a passport.

Okay, that will be difficult, I admit. Would it help to get my key signed
by any official CA? Maybe by our university CA?

> > > I'm aware that there already are Debian packages available from the
> > > project pages, but i'd like to include a debian version in the official
> > > distribution.
> > Hmmm. Of course, I can't stop you from uploading xine packages. And maybe
> > for now, that even makes sense, but eventually, I really want to do that
> > myself.
> I can do the initial packaging, and have you 'take over' after you made it
> trough new-maintainer.

That's almost what I head in mind. Only thing is that I would really like
to happen debianization in our main CVS, in cooperation with the other
xine developers.

> > Any comments? Suggestions?
> Some small comments; i partly agree with you on the packaging-xine-yourself
> part, but there are some parts on wich i disagree.
> - Not having to 'bother' with packaging xine for Debian gives you more time
> to work on the actual code

Well, I would have to bother with debian packaging anyway, as I'm actually
testing xine on several debian machines, and building/installing the
debian package is much faster than rebuilding on every machine...

> - Peer review - if somebody else packages the program, he/she can encounter
> things you wouldn't

Of course, they can. But what keeps anyone from making peer reviews if the
package is maintained by me?

> - the debian package is more than just 'xine' ;) - libmpeg2 and libac3 need
> to be packaged seperately. i'm considering packaging libmpeg2 myself, and a
> colleague of mine intends to package libac3. The xine package/source needs
> to be modified to depend on external libraries, these libraries need to be
> maintained, and the last xine version always has to work with the latest
> library versions (in debian)

Oh oh, stop! You are mislead here. libmpeg2 and libac3 such as libmpg123
as they are used in xine are _highly_ modified. That's why we include them
in the xine sources, and that's why we link them statically. There will
hardly be any chance that xine supports linking to any of those libraries
dynamically, as much of our work consists of modifying those
libraries. Some of the modifications make it to the upstream librarys, but
others don't. End even for those that do, it often takes several months...

> - I've got a full-time job, where part of the job consists of attending to
> my debian packages, so i can spend time on xine when it's needed, and the
> time is (almost) always there (and paid! :) ):)

Lucky you! So I kindly invite you to become a xine developer who takes
specifically care about the debian package for the time being ;-)

> > There are still some open questions about the xine Debian package. Such as
> > it's build for Pentium+ machines, as performance is very critical and it
> > won't run properly on older machines. AFAIK, that violates Debian
> > policies. MIME integration is still missing and such stuff. If you would
> > like to contribute, I would be happy to cooperate with you.
> Hmm, packaging xine for pentium+ packages is hard - also because xine would
> have to run on alpha/sparc/etc cpu's as well. including different binaries
> for different pentium/x86 cpu's would not make sense because of that.
> I'll talk to some people and see what we can think of.

Currently, xine will give very bad performance on non-Pentium+
architectures. However we can, and possiby will, add support for the
multimedia extensions of other architectures in the future. So reasonably
fast PPC or SPARC processors wont be a problem. However, xine will
probably be incompatible with their old ancestors like M68K or
i386. That's the actual problem...

Regards,
	Siggi