[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#710461: marked as done (lintian: non-standard-apache2-module-package-name with multiple modules)

Your message dated Sat, 01 Jun 2013 12:24:34 -0700
with message-id <87txlheirx.fsf@windlord.stanford.edu>
and subject line Re: Bug#710461: lintian: non-standard-apache2-module-package-name with multiple modules
has caused the Debian Bug report #710461,
regarding lintian: non-standard-apache2-module-package-name with multiple modules
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
710461: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710461
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: lintian
Version: 2.5.13
Severity: normal

I have a package (libapache2-mod-webauth) that includes two
closely-related modules.  This triggers this Lintian tag for the
second (mod_webauthldap).

I'm considering breaking the package into two, but I think this is
an acceptable use case when for some reason there are a set of
closely-related modules that make sense to package together.  This
tag should probably gain some of the code that's already present for
shared libraries to not warn about package naming as long as at least
one module in the package satisfies the naming convention.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.8-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils                       2.22-8
ii  bzip2                          1.0.6-4
ii  diffstat                       1.55-3
ii  file                           1:5.14-2
ii  gettext                        0.18.1.1-10
ii  hardening-includes             2.3
ii  intltool-debian                0.35.0+20060710.1
ii  libapt-pkg-perl                0.1.28
ii  libarchive-zip-perl            1.30-6
ii  libclass-accessor-perl         0.34-1
ii  libclone-perl                  0.34-1
ii  libdpkg-perl                   1.16.10
ii  libemail-valid-perl            0.190-1
ii  libfile-basedir-perl           0.03-1
ii  libipc-run-perl                0.92-1
ii  liblist-moreutils-perl         0.33-1+b1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl       0.06~01-2
ii  libtimedate-perl               1.2000-1
ii  liburi-perl                    1.60-1
ii  man-db                         2.6.3-6
ii  patchutils                     0.3.2-1.1
ii  perl [libdigest-sha-perl]      5.14.2-21
ii  t1utils                        1.37-2

Versions of packages lintian recommends:
pn  libperlio-gzip-perl             <none>
ii  perl-modules [libautodie-perl]  5.14.2-21

Versions of packages lintian suggests:
pn  binutils-multiarch     <none>
ii  dpkg-dev               1.16.10
ii  libhtml-parser-perl    3.71-1
ii  libtext-template-perl  1.45-2
ii  xz-utils               5.1.1alpha+20120614-2

-- no debconf information

--- End Message ---
--- Begin Message --- 
Arno Töll <arno@debian.org> writes:

> Hi Russ,

>> I'm considering breaking the package into two, but I think this is an
>> acceptable use case when for some reason there are a set of
>> closely-related modules that make sense to package together.  This tag
>> should probably gain some of the code that's already present for shared
>> libraries to not warn about package naming as long as at least one
>> module in the package satisfies the naming convention.

> I am not so sure, this is reasonably common and a good practice for
> Apache modules. I'm sure there are one or two exceptions in the
> archives, but that's what overrides are for.

> On the downside, there is nothing to gain if you bundle modules
> together, whether they are related or not, right?

Well, you gain some reduced complexity for end users if the modules are
almost always used together (it avoids problems where they get one module
installed and not the other), and it reduces the size of the package list
a tiny bit.

That said, the more I think about it, the more I think I should just go
ahead and split those modules; they're always used together at Stanford,
but in the broader community it's not as clear they would be this tightly
linked.  So I'm going to go ahead and close this bug after further
consideration.  If someone else runs into the same problem, they can
always reopen or open their own bug.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

--- End Message ---
Reply to: