Am Freitag, den 12.12.2008, 13:35 +0100 schrieb Andreas Tille:
> On Fri, 12 Dec 2008, Manuel Prinz wrote:
> > So I wonder if it is reasonable to add -dev packages to the already
> > existing task pages and modify the scripts that generate the
> > meta-packages in a way that they sort out all -dev packages into a
> > $TASK-dev package?
>
> What do you mean by "sort out"?
> The tasks files contain lists of *binary* packages. You have to list all
> binary packages that should be included. There might be a chance to move
> packages named like lib*-dev to a separate *-dev package - but that's a
> weak strategy. There is quite often some more logic required. There are
> even packages which are no -dev library but clearly developer oriented -
> we would loose these. So I do not see an automatic way.
Yes, I was just talking about binary packages and about creating a list
from *-dev packages listed in the task files.
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. 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. 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. Either you want to use it or do development
against it but in any case, it is pulled in by dependencies.
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.
> We *might* consider a separate field inside the tasks files for instance
>
> Dev-{Depends,Recommends,Suggests}: lib*-dev
>
> but frankly I see no profit doing this. It would break several things
> in the current framework for no obvious advantage. Or do I miss something?
I don't know the code that generates the task files, 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 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?" 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.
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.
Best regards
Manuel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil