Re: Adding provides: for Drupal packages
Al Nikolov dijo [Wed, Sep 15, 2010 at 09:35:00AM +0300]:
> > I see with great joy that you are packaging Drupal modules following
> > the naming scheme I came up with, and presumably using my
> > dh-make-drupal tool ;-)
>
> Yes. Every time i develop something new i try to stick to the Debian stable
> and when it's not possible i'm starting to package stuff for Debian as a part
> of the project. dh-make-drupal is an incredibly useful helper!
I am very glad my tool is that useful :) At least, that prompts me
into updating it into DH7 or something like that, as you might have
noticed the generated debian/rules are not particularly strong
(i.e. having all files named explicitly often ends up being
problematic on upgrades)... I have done tens of packages, but have
kept them for personal use (at my repo in
http://www.iiec.unam.mx/apt/) because I don't feel confident enough in
PHP to be a responsible maintainer for them.
> Indeed, this is against Policy which considers Provides as a tool to group
> real packages by functionality, not to reveal internals (as in RPM). In
> particular, when versionned dependency is used, no virtual packages would be
> taken into account. This is why i don't like this approach.
Ok, good thing you agree with my assessment - That means I have to
give some more thought to this. Maybe I should leave the default
behaviour as it has been up to now, and just add a --add-provides
switch so that the people wanting this functionality for their private
packages can add it...
> > Anyway - What I want to do is to either find that information or set
> > up a, say, drupalpkg.debian.net service with this data so that built
> > modules can properly say "Depends: drupal6-mod-cck" when
> > something.info includes a dependency on "content".
>
> I feel, such an external service can end up by an administrative hell
> considering you will have a huge number of dimensions in there.
Well, I don't think it will be that much of a burden, as it is a very
very simple database, with a bit of human validation. But yes, if it
is to be a service, then I have to get committed to maintaining it.
> > Any ideas?
>
> Well, the pretty straightforward idea is to propose an additional field
> for .info (to say, "provides"), which will reveal internals of the module.
> AFAIS it could be filled automatically by Drupal's packaging tools if such
> tools exist. Or you can put your own data there manually instead of #3. In
> result, we will have #2 and wont break the Policy by doing #1.
>
> What do you think?
Of course, it is a possibility, but one that needs pushing into
Drupal (not something I can implement myself). And, given the amount
of modules that are already in existence, it would be most probably
outright dismissed for D6 and probably D7. So, thinking about a
feature for D8 onwards... Does not seem that useful to me if I can
find another way to, sadly.
Besides, that would still leave us translating it to
tons-of-provides.
Reply to: