On Sun, 28 Mar 2004, Tim Cook wrote:
> By maintaining Debian-Med meta packages I just decide which *existing*
> > Debian package will be included in the meta-packages dependencies.
>
> ....I'm confused about this Debian maintainer stuff....
It's quite simple:
- Each person is free to package any Free Software.
(Well he should make sure that it is not yet an official Debian package
because hijacking is against our social rules.)
- If the person which is called package - maintainer is an official
Debian developer he can upload the package to master.
- If the maintainer is no Debian developer he can ask for sponsoring
by a Debian developer who checks the package signs the files and does
the upload. This is explained in detail at
http://www.debian.org/doc/maint-guide/
- New packages will be checked by ftpmaster for compliance with policy.
(You might note that according to my own experiences not every package
is accepted.)
So the maintainer has to work hard to get a policy compliant package
ready to get it into Debian.
- The only thing about Debian-Med regarding packaging are these tiny little
meta packages which start with the name "med-". Their sense is described
in detail in the relevant documentation on top of the page
http://people.debian.org/~tille/debian-med/talks/
I'm glad to accept patches for these packages.
> > Ethos is a philosophical, policy a technical rule. Debian is about
> > technology.
>
> I disagree. There is very much a philosophical angle and it is not
> entirely technical based.
It depends. The layout of a Debian package is a completely technical issue.
The license of the software might have some philosophical aspects. Regarding
to the torch package you prepared I did some technical investigations which
have to be regarded for a successful move into Debian.
BTW, regarding to Zope / Plone packaging issues in Debian you might perhaps
like to subscribe to the Zope package developers mailing list (low traffic)
http://lists.alioth.debian.org/mailman/listinfo/pkg-zope-developers
and bring in your ideas about packaging or enhancing / speeding up Plone 2.0
integration.
> You have my permission, please maintain the context though. The part you
> are referring to here though is really your comments regarding the /opt
> directory.
Well, it's not only about using /opt or not. You agreed here that we
could live without /opt and this is in fact the simplest problem. My
main concern was about doubling some Zope packages inside your package
with different version numbers. It is *really* hard to maintain such stuff
and thus it has to be avoided wherever possible. I have heard that it
is not possible to maintain for instance different versions of Python
inside some distributions. (This is only an example - no connection to
your package here!) In Debian Python 2.[123] work together nicely and
do not conflict with each other. This is the case because a lot of very
clever people (not me ;-) ) worked hard to build a Python-Policy and
get all thinks working together nicely.
So it is similiar with other software. If there is a big need to get different
verisons of one software inside you are not allowed to just put it inside your
package an upload. This is a very technical issue and is one reason why
Debian is famous for its stability. Well, other people call it outdateness -
feel free to insert your favourite attribute here.
So what to do if you want to get more recent versions of Zope / Plone into
Debian. Just join the packaging team. The URL
http://lists.alioth.debian.org/pipermail/pkg-zope-developers/2004-March/thread.html
might prove that we do not ignore this issue. The zope maintainers did a hard
job to enable running different Zope instances on one Debian machine. The problem
is that you have to *work* together with Debian people instead of shouting
about outdateness. Quoting one part of our private discussion:
> On Tue, 24 Feb 2004, Tim Cook wrote:
> > On Tue, 2004-02-24 at 11:32, Andreas Tille wrote:
> > AT> Exactly. Why not filing a bug report including a patch which fixes some
> > AT> imaginary problem you might have with Debian's Plone packages.
> TC> It isn't a bug report to be filed. They are features not available in
> TC> any Debian package.
AT> We have the concept of wishlist bugs ...
If there is any feature missing in Debian you can uses the reportbug tool
to request for these features. I explained in my paper how to find the
relevant links:
http://people.debian.org/~tille/debian-med/talks/paper-cdd/debian-cdd.html/ap-bts.en.html#s-howto_file_bugs
The general rule applies here: Adding patches to the bug report will drastically
speed up fixing the bug. So if there is something missing, just ask for it by
using the tools which are intended for this usage. Claiming that Debian does
some politics you do not like is no problem for me but will not lead to the
result you might want to see. It just proves that you did not read the documents.
> Again, it wasn't my intent to disparage you personally. It was my
> impression that you were sponsoring/maintaining/assembling ?????
> whatever the word, the Debian Med package. In that position you made a
> determination that TORCH is not suitable for inclusion in Debian.
Well, I offered to sponsor any package which is related to medicine. In general
my sponsees are happy with this. ;-) It is my intention to *help* people to
get their stuff directly into Debian (sometimes it is hard to find a sponsor
because of time constraints of each personal maintainer). If you have the
feeling that I'm applying packaging rules to strict you are free to find any
other Debian developer who is willing to sponsor your package. Or you might
even apply as a Debian maintainer yourself (see the URL I mentioned first
in my mail). Than you are free to upload packages yourself. Nobody will
stop you from doing this.
> If you do not support the inclusion of an application for whatever valid
> reason then I would hope it would be fruitless to attempt to get another
> Debian developer to do so. Otherwise, the process and ideals of Debian
> fall apart.
My guess is you will have to try hard to convince any sponsor to upload a
package which might conflict with other packages and even if it will be
uploaded to Debian unstable it will catch RC bugs soon and will not make its
way into testing and stable. Every single user can file RC bugs and keep
your package outside the stable Debian distribution. Thus it simply makes no
sense to upload a package which conflicts with others. It's nothing about
my personal feelings just some experience I gathered in 6 years Debian work
and the fact that Debian developers apply these rules strictly ensures the
stability (and is the result for outdateness - yes). So there are no
ideals involved - we have just to solve technical conflicts.
> > > Really? Is there a Debian Med distribution for download that contains
> > > these packages? I'm sorry, I looked as late as this afternoon and found
> > > no such distribution nor even any "firm list" of packages planned for
> > > distribution that have met Andreas requirements. Can you provide a
> > > link?
> > http://www.debian.org
>
> Sorry, that link didn't help much.
OK, your question was quite unprecise and so my answer was as well. I
was not sure what you was searching for exactly. Under the URL you
should be able to find the link
http://packages.debian.org/
and using the CGI-interface right you will get something like
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-&searchon=names&subword=1&version=all&release=all
This shows you which meta packages exist. If you follow the link to one of the
meta package you can see the list of dependencies. An (currently not yet
existing) package "torch" or "oio" would be listed here and I would have to
build a new meta package med-clinical (or whatever reasonable name). But a
torch package is per definition completely independant from med-clinical and
can live inside Debian nicely without such a meta package. Or even you
are free to build a package med-clinical by either just building it or
volunteering to Co-Maintain Debian-Med packages (which would make more sense).
There is nothing about gods - there is only need for people who to the
actual work.
> I never suggested that you personally do this. I took the idea from the
> Debian Med page and endorsed it as a good idea.
Well - not really - as I tried to explain. Debian-Med packages are just
a wrapper for the installation effort. But Debian-Med is more than building
meta packages. The philosophy of Debian-Med is explained in the paper
I provided the link to above and the general idea of Custom Debian Distributions
(see the other paper under the link above) is to support "specialized users"
(like for instance people working in medicine). One part of this is to
build those meta-packages which should simplify the installation of
interesting packages. A further part is to build packages of specialized
(in my case medical) software. That's why in the list of packages maintained
by me are some packages from the field of micro biology which I also regard
as useful for medical care.
http://qa.debian.org/developer.php?login=tille
Moreover we sponsor several packages for medical care. Most of the packages
from the field of medical imaging are (or were in the past) sponsored by me.
Some of the maintainers who care for medical imaging packages now are even
offical Debian developers themselves.
> Either way, I am not upset about TORCH not being included in Debian Med
> or as an officially blessed Debian package. It doesn't prevent me from
> using a Debian distribution and the wonderful APT system.
Well definitely and this is also one of my goals. If some software is
not included in Debian (for whatever reasons) we would be proud to provide
a solid system for these packages. This is also true for non-free software.
It's better to use a non-free specialized software on a free system instead
of using something else as basis. On the other hand it has advantages to
get your software included into Debian. These are explained in detail in
the Debian-Med paper (see above).
Kind regards
Andreas.
