Provided by: lintian_2.122.0ubuntu1_all bug

NAME

       Lintian::Deb822 -- A deb822 control file

SYNOPSIS

        use Lintian::Deb822;

DESCRIPTION

       Represents a paragraph in a Deb822 control file.

INSTANCE METHODS

       sections
           Array of Deb822::Section objects in order of their original appearance.

       positions
           Line positions

       first_mention
       last_mention
       read_file
       parse_string

FUNCTIONS

   Debian control parsers
       At  first  glance,  this module appears to contain several debian control parsers.  In practise, there is
       only one real parser ("visit_dpkg_paragraph_string") - the rest are convenience functions around it.

       read_dpkg_control(FILE[, FLAGS[, LINES]])
           This is a convenience function to ease using "parse_dpkg_control" with paths to  files  (rather  than
           open  handles).   The  first  argument  must  be the path to a FILE, which should be read as a debian
           control file.  If the file is empty, an empty list is returned.

           Otherwise, this behaves like:

            use autodie;

            open(my $fd, '<:encoding(UTF-8)', FILE); # or '<'
            my @p = parse_dpkg_control($fd, FLAGS, LINES);
            close($fd);
            return @p;

           This goes without saying that may fail with any of  the  messages  that  "parse_dpkg_control(HANDLE[,
           FLAGS[, LINES]])" do.  It can also emit autodie exceptions if open or close fails.

       read_dpkg_control_lc(FILE[, FLAGS[, LINES]])
       parse_dpkg_control_string(STRING[, FLAGS[, LINES]])
           Reads  debian  control  data  from  STRING  and  returns  a list of paragraphs in it.  A paragraph is
           represented via a hashref, which maps (lower cased) field names to their values.

           FLAGS (if given) is a bitmask of the DCTRL_* constants.  Please refer to "CONSTANTS" for the list  of
           constants and their meaning.  The default value for FLAGS is 0.

           If  LINES  is  given,  it should be a reference to an empty list.  On return, LINES will be populated
           with a hashref for each paragraph (in the same order as the returned list).  Each hashref  will  also
           have  a  special  key  "START-OF-PARAGRAPH"  that  gives  the  line number of the first field in that
           paragraph.  These hashrefs will map the field name of the given paragraph to the  line  number  where
           the field name appeared.

           This  is a convenience sub around "visit_dpkg_paragraph" and can therefore produce the same errors as
           it.  Please see "visit_dpkg_paragraph" for the finer semantics of how the control file is parsed.

           NB: parse_dpkg_control does not close the handle for the caller.

       parse_dpkg_control_string_lc(STRING[, FLAGS[, LINES]])
       lowercase_field_names
       visit_dpkg_paragraph_string (CODE, STRING[, FLAGS])
           Reads debian control data from STRING and passes each paragraph to CODE.  A paragraph is  represented
           via a hashref, which maps (lower cased) field names to their values.

           FLAGS  (if given) is a bitmask of the DCTRL_* constants.  Please refer to "CONSTANTS" for the list of
           constants and their meaning.  The default value for FLAGS is 0.

           If the file is empty (i.e. it contains no paragraphs), the method will contain an  empty  list.   The
           deb822 contents may be inside a signed PGP message with a signature.

           visit_dpkg_paragraph  will  require  the  PGP headers to be correct (if present) and require that the
           entire file is covered by the signature.  However, it will not validate the signature (in  fact,  the
           contents of the PGP SIGNATURE part can be empty).  The signature should be validated separately.

           visit_dpkg_paragraph  will  pass  paragraphs  to CODE as they are completed.  If CODE can process the
           paragraphs as they are seen, very large control files  can  be  processed  without  keeping  all  the
           paragraphs in memory.

           As  a consequence of how the file is parsed, CODE may be passed a number of (valid) paragraphs before
           parsing is stopped due to a syntax error.

           NB: visit_dpkg_paragraph does not close the handle for the caller.

           CODE is expected to be a callable reference (e.g. a sub) and will be invoked as the following:

           CODE->(PARA, LINE_NUMBERS)
               The first argument, PARA, is a hashref to the most recent paragraph parsed.  The second argument,
               LINE_NUMBERS, is a hashref mapping each of the field names to the line  number  where  the  field
               name  appeared.   LINE_NUMBERS  will  also have a special key "START-OF-PARAGRAPH" that gives the
               line number of the first field in that paragraph.

               The return value of CODE is ignored.

               If the CODE invokes die (or similar) the error is propagated to the caller.

           On syntax errors, visit_dpkg_paragraph will call die with the following string:

             "syntax error at line %d: %s\n"

           Where %d is the line number of the issue and %s is one of:

           Duplicate field %s
               The field appeared twice in the paragraph.

           Continuation line outside a paragraph (maybe line %d should be " .")
               A continuation line appears outside a paragraph - usually caused  by  an  unintended  empty  line
               before it.

           Whitespace line not allowed (possibly missing a ".")
               An  empty  continuation line was found.  This usually means that a period is missing to denote an
               "empty line" in (e.g.) the long description of a package.

           Cannot parse line "%s"
               Generic error containing the text of the line that confused  the  parser.   Note  that  all  non-
               printables in %s will be replaced by underscores.

           Comments are not allowed
               A comment line appeared and FLAGS contained DCTRL_NO_COMMENTS.

           PGP signature seen before start of signed message
               A "BEGIN PGP SIGNATURE" header is seen and a "BEGIN PGP MESSAGE" has not been seen yet.

           Two PGP signatures (first one at line %d)
               Two "BEGIN PGP SIGNATURE" headers are seen in the same file.

           Unexpected %s header
               A valid PGP header appears (e.g. "BEGIN PUBLIC KEY BLOCK").

           Malformed PGP header
               An invalid or malformed PGP header appears.

           Expected at most one signed message (previous at line %d)
               Two "BEGIN PGP MESSAGE" headers appears in the same message.

           End of file but expected an "END PGP SIGNATURE" header
               The  file  ended  after  a  "BEGIN  PGP  SIGNATURE"  header without being followed by an "END PGP
               SIGNATURE".

           PGP MESSAGE header must be first content if present
               The file had content before PGP MESSAGE.

           Data after the PGP SIGNATURE
               The file had data after the PGP SIGNATURE block ended.

           End of file before "BEGIN PGP SIGNATURE"
               The file had a "BEGIN PGP MESSAGE" header, but no signature was present.

AUTHOR

       Originally written Christian Schwarz and many other people.

       Moo version by Felix Lechner <felix.lechner@lease-up.com> for Lintian.

SEE ALSO

       lintian(1)

Lintian v2.122.0ubuntu1                            2025-05-01                                 Lintian::Deb822(3)