Re: RFC: Profile as check/tag loader
On Wed, Jan 18, 2012 at 11:03:58PM +0100, Niels Thykier wrote: Hi, Hi, I have been coding a bit and I got an idea that I would like to share before just merging my branch (at [1]). I originally wanted to start on the vendor-specific data files, but it turned into some rather large structural changes. Hench this mail. I've been rather quiet recently - my apologies. I thought I would quickly jump in here to say thanks for your detailed emails and yes I agree with this plan moving forward. I hope to implement a new vendor file in 2012 so this functionality that you've described below is something I'll use. Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120122130303.ga3...@shadowfax.dlinkddns.com
Re: Example of proposed pod usage (with patch)
On Aug 13, 2011, at 13:06, Niels Thykier wrote: On 2011-08-12 22:34, Jeremiah C. Foster wrote: Here is an example of how I think pod might work; Hey, I appreciate the idea of improving the documentation and making (htmlified-version of) README.developers appear on lintian.d.o was a very nice idea. :) I thinking we can (ab)use some headings in the README.developers. My attachment is an example, I am not sure how well it works (I am mostly used to do pod as a part of perl scripts/modules). I agree on both points; we shouldn't abuse pod and . . . BTW, I committed your original README.developers with a few changes[1], so your patch would probably not apply cleanly. thanks for your changes, they clarify my draft text. I'll merge into my separate repo https://github.com/jeremiah/lintian-jeremiah-branch just so it is easier for me to follow. I'll still send patches to the list in the format suggested unless you'd rather pull? For the frontend/* files, what would we want in the pod? Personally I am used to embed the manpage-pod in that file, but we have it (and partly need it to be) in a separate file (man/*). So what are we looking for here? I'm going to defer to you and Russ in this regard. I'd hesitate to change a well functioning workflow. I am happy to document stuff (mostly for my own sake so I can understand the code) when I see it not documented and I can adapt to whichever format. Personally I would probably skip the LEGAL part; if anything I would include a 2-3 line LICENSE in the bottom[2]. Otherwise I think it would just be in the way. Yup. +1 Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ccf09ad5-104a-47f5-892c-006222629...@jeremiahfoster.com
Re: Example of proposed pod usage (with patch)
On Aug 13, 2011, at 19:08, Niels Thykier wrote: On 2011-08-13 13:21, Jeremiah C. Foster wrote: BTW, I committed your original README.developers with a few changes[1], so your patch would probably not apply cleanly. thanks for your changes, they clarify my draft text. I'll merge into my separate repo https://github.com/jeremiah/lintian-jeremiah-branch just so it is easier for me to follow. I'll still send patches to the list in the format suggested unless you'd rather pull? I forgot to mention that I wrote a wiki page[1] that may help you (or others) Very useful, thanks! Jeremiah -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/26b8e130-03ed-4923-abc1-766dc6850...@jeremiahfoster.com
Re: [SCM] Debian package checker branch, master, updated. 2.5.2-11-g39af0d7
On Aug 13, 2011, at 23:57, Niels Thykier wrote:
On 2011-08-13 23:13, Russ Allbery wrote:
Niels Thykier ni...@thykier.net writes:
Perlcritic cleaned c/standards-version
-our $STANDARDS = Lintian::Data-new('standards-version/release-dates',
'\s+');
+my $STANDARDS = Lintian::Data-new('standards-version/release-dates',
qr/\s+/o);
These are file globals -- why would one use my instead of our? Do you
know what the rationale of perlcritic is here?
-our $CURRENT = $STANDARDS[0][0];
-our @CURRENT = split(/\./, $CURRENT);
+my $CURRENT_VER = $STANDARDS[0][0];
+my @CURRENT = split(m/\./, $CURRENT_VER);
*grumble*. This is one of the reasons why I don't particularly like
perlcritic. Those two variables contain exactly the same information,
just in one case as a string and in another case as an array, which you
can represent in Perl with the same variable name as a scalar and as an
array. Using different variable names for them is obfuscating, not adding
clarity.
I don't really care that much, and I'm all in favor of picking a coding
style and following it uniformly even if it isn't the one I'd choose, so
I'm not saying to change this back. But I do think perlcritic is wrong
about this.
Turns out this particular these two were not Perlcritic issues (I
applied these fixes from my memory of previous Perlcritic issues).
So the my vs. our, I seem to have confused our with use vars in
terms of Perlcritic warnings. As for my vs. our, it is my
understanding that our makes the variable public[0] and it seems to
me these variables are not actually intended to be used outside of
checks/standards-version.
On the other issue, I thought the $C, @C-thing was covered by the
re-use of same variable in lexical scope, but it turns out it isn't
(probably due to the types being different).
I can see the idea behind it now, sort of like a C-string where you
can process the string as a whole (strcmp(s, text)) or individual
characters (s[0]). I guess the perl way of doing that is to declare two
variables with same name and different type.
Yeah, this is exactly what perl does. The sigil is meant to be the mnemonic,
so you know that $ is scalar and @ is array.
In the given case I can see the use of this. That being said, I have
my concerns blessing wide-spread use of this. You may remember I got a
bit confused with:
$checks or ($checks = join(',',keys %check_info));
[...]
$checks{$c} = 1;
from frontend/lintian in 2.4.3: $checks was a comma-separated list and
%checks was a hash where the keys were elements from said list.
It looks like in this case the second $checks is actually a reference to a hash.
More: http://oreilly.com/catalog/advperl/excerpt/ch01.html
Can you point me to the section on my ($v, @v, %v); in the perl
documentation (not really sure what to look/google for here). I would
like to get a second look on this. :)
Perl has a rich set of datatypes, that URL above describes most of those that
you'll run into, i.e. scalars, arrays, hashes and references to all three.
Regards,
Jeremiah
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/b84e8793-dae4-493d-ba31-b170c3619...@jeremiahfoster.com
Re: [Draft] Bits from the lintian maintainers
On Aug 12, 2011, at 21:36, Jeremiah Foster wrote: I've got a question regarding the various lintian modules. I'm a command line person and often use tools like perldoc to read the documentation that is in with code. Lintian does seem to use I meant doesn't of course. :} plain old documentation very much which I think is too bad. It is considered a perl best practice. I'm happy to add that type of pod to the modules and the scripts as I come across the need. Is that useful? I'd also like to move the README.Developer from plain text to pod while it is still early. pod can get translated into markdown and Mediawiki markup as well as html. Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/82741958-a5f5-47a9-b55d-97ea8286f...@jeremiahfoster.com -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4181e7b0-52d6-44f7-90e1-7aee5aa2a...@jeremiahfoster.com
Example of proposed pod usage (with patch)
Here is an example of how I think pod might work;
---
README.developers |6 -
frontend/lintian | 60 ++--
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/README.developers b/README.developers
index dc1edd0..ca4b206 100644
--- a/README.developers
+++ b/README.developers
@@ -1,4 +1,6 @@
-README.Developers for the Lintian tool
+=pod
+
+Readme.Developers for the Lintian tool
---
Lintian dissects Debian packages and tries to find bugs and policy
@@ -13,3 +15,5 @@ directory frontend. This directory holds the lintian
executable.
This is what gets called when a user calls lintian. The frontend
then calls the lintian checks which run over the Debian package
that Lintian is checking.
+
+=end
diff --git a/frontend/lintian b/frontend/lintian
index 0625b61..907e747 100755
--- a/frontend/lintian
+++ b/frontend/lintian
@@ -1,27 +1,45 @@
#!/usr/bin/perl -w
-# {{{ Legal stuff
-# Lintian -- Debian package checker
-#
-# Copyright (C) 1998 Christian Schwarz and Richard Braakman
-#
-# This program is free software. It is distributed under the terms of
-# the GNU General Public License as published by the Free Software
-# Foundation; either version 2 of the License, or (at your option) any
-# later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, you can find it on the World Wide
-# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
-# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
-# MA 02110-1301, USA.
-# }}}
+
+=head1 NAME
+
+Lintian -- Debian package checker
+
+=over 2
+
+=item ./frontend/lintian
+
+=back
+
+=head1 LEGAL
+
+=over 2
+
+Copyright (C) 1998 Christian Schwarz and Richard Braakman
+
+This program is free software. It is distributed under the terms of
+the GNU General Public License as published by the Free Software
+Foundation; either version 2 of the License, or (at your option) any
+later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program. If not, you can find it on the World Wide
+Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
+Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+MA 02110-1301, USA.
+
+=back
+
+=cut
+
+
# {{{ libraries and such
+
use strict;
use warnings;
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110812203406.ga5...@shadowfax.dlinkddns.com
Re: Vendor-based customization of Lintian (or profiles)
On Tue, Apr 19, 2011 at 06:14:25PM +0200, Niels Thykier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Considering that #513663 will be closed in 2.5.0~rc3, I figured it was time to start a new branch. XD w00t! I was considering to do either Vendor-based customization or support third party checks (e.g. Lintian extra), as the subject suggests I think I will start with Vendor-based Lintian. However if you think third party checks should be given priority, let me know - this decision is not set in stone. :) I strongly feel vendor based customizations should be the Next Big Thing. I started a fork of lintian in Maemo, called maemian, but it quickly bogged down due to the complexities you mention in Ubuntu. The point is that I think this would be welcome amongst derivatives and improve the quality of derivative package and ultimately Debian. I'm very glad that you're looking into doing this Niels - thank you. And thank you for your work on lintian. To be honest, I've rarely seen more productive programmers than yourself! Thanks! Jeremiah -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419210251.GA7526@localhost
