Re: New -dev tasks
On Fri, 12 Dec 2008, Manuel Prinz wrote:
I do not know if there are libraries without any -dev packages. Having a
library package installing development files seems like bad packaging
practice to me.
It's not all about libraries. Have a look at
http://debian-med.alioth.debian.org/tasks/bio-dev.html
BioPerl, libbio-mage-perl, libbio-ruby, ... are examples for developer
oriented packages that do not end with -dev extension. So there is no
good automatic way to differentiate between developer or user oriented
packages if you want to guess from the name of the package.
The naming of a single library package does not seem
neccessary to me either. If you have a user app in a package using a
library, it depends on it, so APT will install it when it installs the
package containing the app.
Yes. That's why such packages should be listed in the user oriented
task. The binary library package does not have to be listed explicitely.
Development packages also depend on the
library they contain headers/sonames for because the library is needed
by the linker. So there is no need to list a library binary package in
the task files at all.
Full agreement. I just fixed
$ svn diff
Index: bio-dev
===================================================================
--- bio-dev (Revision 1268)
+++ bio-dev (Arbeitskopie)
@@ -15,7 +15,7 @@
Depends: libqsearch-dev
-Depends: libgenome-1.3-0
+Depends: libgenome-1.3-0-dev
Depends: libbio-mage-perl
Why: Useful for the submission of microarray data to public repositories.
Either you want to use it or do development
against it but in any case, it is pulled in by dependencies.
Yes. That's what we are actually doing in bio-dev / imaging-dev (modulo
some bugs - see above).
The only problem I see is about library packages not following the -dev
convention. I can't recall if it's a suggestion or defined in the
policy, but either way such a package is buggy, IMHO.
There are other developer oriented packages than libraries - see above.
I don't know the code that generates the task files,
Neither do I know the code of my favourite editor. ;-)
Well, the task files are plain simple RFC822 files - have a look into SVN!
so I can't comment
on the fact that it breaks things. I take your word on it. Breakage is
of course not intended, I assumed to current code to be able to handle
that with just minor modifications.
The tasks files are used as input for:
debian/control (done by blend-gen-control of blends-dev package)
$BLEND-tasks.desc (done by blend-gen-control of blends-dev package)
tasks page (done by tasks.py of webtools)
bugs page (done by bugs.py of webtools)
registration mails to have nice sectioning on qa pages (done by ddpo_register.py)
So all this stuff has to be touched (well not really, because the first
two and the last three are using the same code) to implement a change
which makes things more complicated for very less profit (at least I see
no profit).
The advantage IMHO is that you have the information in the same file
which may be easier to maintain. One can more easily address questions
like "There are packages using $MYLIB, do we also have the development
files listed?"
The only real argument would be if you just list a source package and there
would be a safe method to obtain a tools / apps binary package as well as
a -dev package out of the source packages name. Because there is no such
method (to my knowledge) we have to list the binary packages anyway. As I
argued above we have to deal with separate user / developer tasks files anyway
so listing the -dev package there is not really much work (at least it does
not rectify the high chances to break something).
I'm unsure if that is a use case, though. But things just
tend to get out-of-sync quickly when several people are working on it
simulateneously.
Well, there is a slight chance that you forget to ass a -dev package if
you list the apps / tools package in one tasks file - but there is also
a good chance that you will forget to add the -dev package in the user
file and so the "automatical move -dev" magic would not work anyway.
I have no strong feelings on how it is done, I just wanted to comment on
it and address the concerns I had when reading Sylvestre's
proposal/question.
I don't say that I'm not open for suggestions. ;-)
I'm just not yet convinced that the implementation of this suggestion
is something I would like to do in the next decade. ;-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: