Bug#501688: Getting dh-make-perl to use META.yml
Paul Fenwick dijo [Tue, Nov 18, 2008 at 09:13:38PM +1100]: G'day everyone, I got stalled slightly by having a big hunk of work land on me, but I'm looking through dh-make-perl again now. I've noticed that the indenting and bracing tends to wander around a bit, which can make the program flow hard to follow in parts. I'm hoping to standardise the code layout, and wanted to check if we have a preferred indentation level and bracing style? If not, I'll use the Perl Best Practices recommendations of KR braces, uncuddled elses, 4-space indents, and no tabs. Well, even though that might not be my personal style, I agree that any coding standard is better than no coding standard ;-) From my part, please go ahead and improve dh-make-perl the best you can. Many of us have done so (or tried to do so) at different points in time, but with... unfinished results ;-) Besides, my participation in the group seems to be quite erratic - I am still and plan to continue being an active part of it (at least, for some definition of active), but please weigh others' opinions higher than mine. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
Damyan Ivanov dijo [Tue, Nov 18, 2008 at 01:19:14PM +0200]: If you still feel like re-indenting the whole file, send that as a separate patch (perhaps before the real/functional patch). Completely agree with this. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
-=| Paul Fenwick, Wed, Nov 19, 2008 at 12:25:50AM +1100 |=- gregor herrmann wrote: I think it would be helpful if someone cleaned up the file and changed it to a consistent style. But I agree that it would be better to have that before/separate from any substantial patch in order to make reviewing easier. I'm very familiar with the idea of separating formatting changes from functional changes, so I'll be sending a patch (possibly a few) which will be changes to whitespace and comments only. Nice. Sorry if I was pointing things that are obvious to you. I also want to talk about automated tests, since I hate changing any code when I don't have tests to go with it. Unfortunately it's rather late here in Australia, so I'll need to discuss this when my eyes aren't drooping. *sigh* dh-make-perl has no test suite. I guess the only testing we apply is of the smoketest type. I'm assuming at the moment that I should post patches to the bug. If not, then feel free to enlighten me. If you'd prefer me to point you at my git repo, and say pull this branch, that also works for me. Either way should work. -- damJabberID: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#501688: Getting dh-make-perl to use META.yml
G'day everyone, I got stalled slightly by having a big hunk of work land on me, but I'm looking through dh-make-perl again now. I've noticed that the indenting and bracing tends to wander around a bit, which can make the program flow hard to follow in parts. I'm hoping to standardise the code layout, and wanted to check if we have a preferred indentation level and bracing style? If not, I'll use the Perl Best Practices recommendations of KR braces, uncuddled elses, 4-space indents, and no tabs. Cheerio, Paul -- Paul Fenwick [EMAIL PROTECTED] | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
-=| Paul Fenwick, Tue, Nov 18, 2008 at 09:13:38PM +1100 |=- I got stalled slightly by having a big hunk of work land on me, but I'm looking through dh-make-perl again now. I've noticed that the indenting and bracing tends to wander around a bit, which can make the program flow hard to follow in parts. Try setting the tab wisth to 8 (set ts=8 in vim). I'm hoping to standardise the code layout, and wanted to check if we have a preferred indentation level and bracing style? If not, I'll use the Perl Best Practices recommendations of KR braces, uncuddled elses, 4-space indents, and no tabs. Any readable indentation/brace style is acceptable. Please don't re-indent the whole file, just the parts you change. If you still feel like re-indenting the whole file, send that as a separate patch (perhaps before the real/functional patch). Thank you for your time. -- damJabberID: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#501688: Getting dh-make-perl to use META.yml
On Tue, 18 Nov 2008 13:19:14 +0200, Damyan Ivanov wrote:
I'm hoping to standardise the code layout, and wanted to check if we have a
preferred indentation level and bracing style? If not, I'll use the Perl
Best Practices recommendations of KR braces, uncuddled elses, 4-space
indents, and no tabs.
Any readable indentation/brace style is acceptable.
Ack.
Please don't re-indent the whole file, just the parts you change.
If you still feel like re-indenting the whole file, send that as
a separate patch (perhaps before the real/functional patch).
I think it would be helpful if someone cleaned up the file and
changed it to a consistent style. But I agree that it would be better
to have that before/separate from any substantial patch in order to
make reviewing easier.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-She won' go Warp 7, Cap'n! The batteries are dead!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
gregor herrmann wrote: I think it would be helpful if someone cleaned up the file and changed it to a consistent style. But I agree that it would be better to have that before/separate from any substantial patch in order to make reviewing easier. I'm very familiar with the idea of separating formatting changes from functional changes, so I'll be sending a patch (possibly a few) which will be changes to whitespace and comments only. I also want to talk about automated tests, since I hate changing any code when I don't have tests to go with it. Unfortunately it's rather late here in Australia, so I'll need to discuss this when my eyes aren't drooping. I'm assuming at the moment that I should post patches to the bug. If not, then feel free to enlighten me. If you'd prefer me to point you at my git repo, and say pull this branch, that also works for me. Cheerio, Paul -- Paul Fenwick [EMAIL PROTECTED] | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
G'day Gunnar, Mark, and anyone else reading this ticket. Firstly, this is my first time responding to a Debian bug. If I've missed something, or misunderstood the bug process, please let me know; I'm eager to be educated. I'm one of the Module::Install developers, and I've also been bitten by dh-make-perl via Module::Depends::Intrusive failing to parse certain Makefile.PL files. However I'm a little confused as to why we'd want to, since all modern CPAN modules should have a META.yml file. Put very simply, all the meta information about a module, including its dependencies, are placed in a machine-readable file so that systems such as CPAN testing tools, dh-make-perl, and anything else can read them. To give an example, the Perl::Critic module has a complicated build system that dh-make-perl currently chokes on. However the META.yml file is easily understood (the requires list is near the top of the file): http://search.cpan.org/src/THALJEF/Perl-Critic-1.092/META.yml It strikes me that dh-make-perl is best using the META.yml file if it exists, and then only falling back on Module::Depends::Intrusive and other techniques if required. This *should* solve all the Module::Install and Module::Build problems, since both those systems automatically generate META.yml files, as do modern versions of ExtUtils::MakeMaker. The full META.yml spec can be found at: http://module-build.sourceforge.net/META-spec.html The META.yml files should be readable by just about any language, including Perl (via the YAML or YAML::Syck modules)[1]. If dh-make-perl is already moving toward META.yml support, then I'd be happy to offer assistance. If it's not, but you think it's a good idea, then I'd be happy to do the coding, or find a volunteer who can. Many thanks, and all the very best, Paul [1] More about YAML as a mark-up can be found at http://en.wikipedia.org/wiki/YAML -- Paul Fenwick [EMAIL PROTECTED] | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
On Sun, 16 Nov 2008 21:03:08 +1100, Paul Fenwick wrote:
Firstly, this is my first time responding to a Debian bug. If I've missed
something, or misunderstood the bug process, please let me know; I'm eager
to be educated.
That's fine, thanks for your comments.
I'm one of the Module::Install developers, and I've also been bitten by
dh-make-perl via Module::Depends::Intrusive failing to parse certain
Makefile.PL files. However I'm a little confused as to why we'd want to,
since all modern CPAN modules should have a META.yml file.
I looked at the code, and it's a bit strange:
dh-make-perl uses the META.yml file -- but not for calculating the
dependencies. extract_depends() is even passed the meta hash but it's
never used then.
Don't ask my why, probably a phenomenon of organically grown :/
It strikes me that dh-make-perl is best using the META.yml file if it
exists, and then only falling back on Module::Depends::Intrusive and other
techniques if required.
That's what dh-make-perl already does for getting the license, or the
abstract or the author ... so it seems logical for the dependencies
too.
But maybe there was/is a reason to do it differently that I'm not
aware of.
If dh-make-perl is already moving toward META.yml support, then I'd be happy
to offer assistance. If it's not, but you think it's a good idea, then I'd
be happy to do the coding, or find a volunteer who can.
We're always happy about improvements and patches.
If you want to take a look at dh-make-perl please grab the version
from our subversion repository:
svn {co,export}
svn://svn.debian.org/svn/pkg-perl/trunk/dh-make-perl/dh-make-perl
or
http://svn.debian.org/viewsvn/pkg-perl/trunk/dh-make-perl/dh-make-perl?view=markup
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Rolling Stones: Wild
signature.asc
Description: Digital signature
Bug#501688: Getting dh-make-perl to use META.yml
gregor herrmann dijo [Sun, Nov 16, 2008 at 03:18:15PM +0100]: Firstly, this is my first time responding to a Debian bug. If I've missed something, or misunderstood the bug process, please let me know; I'm eager to be educated. That's fine, thanks for your comments. I also want to thank you for looking into our ugly but beloved tool ;-) I'm one of the Module::Install developers, and I've also been bitten by dh-make-perl via Module::Depends::Intrusive failing to parse certain Makefile.PL files. However I'm a little confused as to why we'd want to, since all modern CPAN modules should have a META.yml file. I looked at the code, and it's a bit strange: dh-make-perl uses the META.yml file -- but not for calculating the dependencies. extract_depends() is even passed the meta hash but it's never used then. Don't ask my why, probably a phenomenon of organically grown :/ Organically... I hope the onions I have in my garden are not as dirty as dh-make-perl's internals ;-) I cannot recall the exact details... But I do recall there was a reason for using M::D::I instead of META - I am just guessing, but I think it is related to Paul's statement, «all modern CPAN modules should have a META.yml file». Very often, we need -or are requested to- package _very_ old modules. And CPAN is full of perfectly-functioning but no-longer-maintained modules. Which lack a META file, or whose META file is incomplete/outdated. Of course, a sensible behaviour would be to parse META if it is available (for dependencies), and only use M::D::I if it is not - or if specified via a command-line switch or so. I do believe Paul's comment should be addressed. But, yes, I'd love for someone else (with better grasp of real reasons, not just my I believe stuff ;-) ) can comment on this. OTOH, as we have some upstream Perl people with more proper CPAN participation: How would it go regarding CPAN customs to update those stale distributions I mention? Making a new, minor-version upload of CPAN packages bringing them to updated standards, even if they authors are no longer active? Something akin to Debian's NMUs - with the added bonus that it can help spot distributions which need to be adopted by somebody else... Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
-=| Gunnar Wolf, Sun, Nov 16, 2008 at 09:46:52AM -0600 |=- I cannot recall the exact details... But I do recall there was a reason for using M::D::I instead of META - I am just guessing, but I think it is related to Paul's statement, «all modern CPAN modules should have a META.yml file». Very often, we need -or are requested to- package _very_ old modules. And CPAN is full of perfectly-functioning but no-longer-maintained modules. Which lack a META file, or whose META file is incomplete/outdated. Just an idea: Outdated META can be detected by insecting the meta-space/version field or even generated_by. We could also translate the optional dependencies into Debian's Suggests. All in all, META.yml seems like a good source of information to me. Even if not perfect in all cases, the results are supposed to be inspected by a human anyway :) -- damJabberID: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#501688: Getting dh-make-perl to use META.yml
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
G'day everyone,
Quick policy check for me: Should I be replying just to the bug, or to
everyone, including the bug? At the moment I'm assuming the former, with
apologies to Gunnar, who's receiving this message twice. ;)
(Also apologies to
Gunnar Wolf wrote:
Of course, a sensible behaviour would be to parse META if it is
available (for dependencies), and only use M::D::I if it is not - or
if specified via a command-line switch or so.
Looks like we're in agreement here!
OTOH, as we have some upstream Perl people with more proper CPAN
participation: How would it go regarding CPAN customs to update those
stale distributions I mention? Making a new, minor-version upload of
CPAN packages bringing them to updated standards, even if they authors
are no longer active?
I'm not a CPAN admins, but I'm fairly familiar with the procedure when it
comes to stale distributions.
Put simply, if reasonable and multiple attempts have been made to contact
the author of a module, and a reasonable amount of time has passed, then
maintenance of the module can be assigned to someone else. Usually this
means that module reassignment is successful, as the old author is happy for
someone else to maintain it, or never responses.
The big sticking point is if a module author responds, but says no. Even if
they have no intention of fixing their code ever, CPAN policy dictates that
a module can't be reassigned by force. Luckily, this rarely happens.
I imagine that for once-off, this module needs a META.yml style changes
the same procedure would apply. If contacting the upstream author fails,
then mailing [EMAIL PROTECTED] would be how one would start such a change.
Gregor wrote:
We're always happy about improvements and patches.
If you want to take a look at dh-make-perl please grab the version
from our subversion repository:
svn {co,export} svn://svn.debian.org/svn/pkg-perl/trunk/dh-make-perl/
Thanks, I've got the code and am looking through it now. Are general
tidy-up patches appreciated, or should I restrict changes to those
relating this specific bugs (like this one)? In any case, changes for
tidy-up and bug-fixes will be sent in separate patches from me.
What's the minimum version of Perl I can assume for changes to dh-make-perl?
(Currently it looks like it requires at least Perl 5.6).
Cheerio,
Paul
- --
Paul Fenwick [EMAIL PROTECTED] | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
iD8DBQFJIKHPx5N6j7FHnlURAnJ/AJ9ov07DsVSpKVacQEb7uT3udx7XcgCfWxS0
LxLdhCHB5NYATEQ9lRu8LTU=
=+Unq
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501688: Getting dh-make-perl to use META.yml
On Mon, 17 Nov 2008 09:42:25 +1100, Paul Fenwick wrote:
Quick policy check for me: Should I be replying just to the bug, or to
everyone, including the bug? At the moment I'm assuming the former, with
apologies to Gunnar, who's receiving this message twice. ;)
In this case replying to the bug should be enough; mails are
forwarded to the maintainer of the bug's package which for
dh-make-perl is a mailing list which all involved people are reading
anyway.
Of course, a sensible behaviour would be to parse META if it is
available (for dependencies), and only use M::D::I if it is not - or
if specified via a command-line switch or so.
Looks like we're in agreement here!
Ack.
(BTW: the command line switch --nometa already exists and is used for
other extraction stuff.)
svn {co,export} svn://svn.debian.org/svn/pkg-perl/trunk/dh-make-perl/
Thanks, I've got the code and am looking through it now.
Great!
Are general
tidy-up patches appreciated, or should I restrict changes to those
relating this specific bugs (like this one)? In any case, changes for
tidy-up and bug-fixes will be sent in separate patches from me.
As dh-make-perl is a bit of a mess I think we're happy about all
proposed improvals.
What's the minimum version of Perl I can assume for changes to dh-make-perl?
(Currently it looks like it requires at least Perl 5.6).
IIRC 5.6-something comes from the Debian Perl Policy [0], in pratice
even sarge had already 5.8.4-8sarge6 (and etch, which will be
oldstable after lenny is released, has 5.8.8-7etch3).
Thanks for your offer to help us with dh-make-perl!
Cheers,
gregor
[0]
http://www.debian.org/doc/packaging-manuals/perl-policy/
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: U2: Seconds
signature.asc
Description: Digital signature
