Adding provides: for Drupal packages

[Gunnar Wolf]

Hi,

[ Cc:ing debian-webapps, to get more possible interested people in
the loop ]

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 ;-)

I have not yet uploaded my latest changes to Debian (and will probably
revert them if I find a better alternative), but you can fetch them at
http://github.com/gwolf/dh-make-drupal ; what I added since 0.7 is the
generation of a Provides: line for all provided submodules (that is,
for every *.info file inside the module). I am still uncertain whether
this is a good move, as it is not policy-clean (i.e. I'm just
inventing virtual package names), but it works at least for my locally
built packages. What I was thinking about doing is to find where in
Drupal's site are such provides:-equivalents spelt out (as I'm almost
sure a module can point out to what module it requires!)

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".

Any ideas?

[Al Nikolov]

[sorry for resending this, due to a silly restriction of lists.d.o]

Hi, Gunnar

Post by Gunnar Wolf
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!

#1

Post by Gunnar Wolf
I have not yet uploaded my latest changes to Debian (and will probably
revert them if I find a better alternative), but you can fetch them at
http://github.com/gwolf/dh-make-drupal ; what I added since 0.7 is the
generation of a Provides: line for all provided submodules (that is,
for every *.info file inside the module). I am still uncertain whether
this is a good move, as it is not policy-clean (i.e. I'm just
inventing virtual package names), but it works at least for my locally
built packages.

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.

#2

Post by Gunnar Wolf
What I was thinking about doing is to find where in
Drupal's site are such provides:-equivalents spelt out (as I'm almost
sure a module can point out to what module it requires!)

I'm not so sure, i'm afraid. Since there's no automatic way to download
modules (in D6, at least; what about D7?), they just don't need this info.

#3

Post by Gunnar Wolf
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.

Post by Gunnar Wolf
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?

[Gunnar Wolf]

Post by Al Nikolov

Post by Gunnar Wolf
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.

Post by Al Nikolov
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...

Post by Al Nikolov

Post by Gunnar Wolf
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.

Post by Al Nikolov

Post by Gunnar Wolf
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.