-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-06 01:15, Russ Allbery wrote:
> Niels Thykier <ni...@thykier.net> writes:
>
>> I have had a look at this nearly 2 year old bug and I think it would be
>> great if we could find a solution for cross-package checks. To make it
>> even better I am interested in working on this. That being said I have
>> not work on Lintian for very long so ...
>
>> Is it correctly asserted that we always check source packages first
>> because this is the only way we currently have to guarantee that the
>> information from the source package unpacked when checking a binary
>> (assuming the source is present at all)? Or is there also another reason
>> for this ordering (e.g. some undocumented assumption on this)?
>
> It looks like we currently check source packages first in the normal mode
> of running lintian on a *.changes file as an artifact of the fact that
> dpkg-genchanges always lists the source package first. The code (in
> Lintian::Schedule) doesn't do anything particularly intelligent.
>
Really? Judging from Lintian::Schedule I would say it is partly
enforcing this regardless of the output order of dpkg-genchanges
# for each package (the sort is to make sure that source packages are
# before the corresponding binary packages--this has the advantage that
binary
# can use information from the source packages if these are unpacked)
my %type_sort = ('b' => 1, 'u' => 1, 's' => 2, 'c' => 3 );
sub get_all {
return sort({$type_sort{$b->{type}} <=> $type_sort{$a->{type}}}
@{$_[0]->{schedule}});
}
> It is definitely the case that we need to check the source package before
> the binary packages, or at least unpack the source package before checking
> the binary packages, if we want to use metadata about the source package
> in the binary package checks. I think all the cross-package checks we've
> run into so far have wanted things in that order: binary checks wanting
> things from the source package, but not the source checks wanting things
> from binary packages.
>
> If we start explicitly taking advantage of this by doing more
> cross-package testing, we should modify Lintian::Schedule to ensure that
> all source packages are checked before all binary packages even if people
> are doing things like lintian *.deb *.dsc.
>
As I understand "cross-package", we are looking at trying to ensure that
all binary/udeb packages produced from a single source package is
unpacked before any of binaries/udebs and even the source itself is
checked. That is:
lintian A.changes B.changes
then when lintian checks any package from A.changes, then all packages
from A.changes are unpacked to the minimum required level required by
the check being run on the current package.
If so, I do not see an issue with processing one source package
immediately followed by its binaries/udebs before continuing to the next
source package[1]. Or were you simply mentioning that lintian must
produce the same results for lintian *.dsc *.deb vs. lintian *.deb *.dsc?
About the ordering itself: As long as the source package or the changes
file is passed, we got all the information needed to generate a correct
ordering for these packages.
But what about multiple binaries without a source? If a user passes
*.deb, should lintian then try to order the packages such that binary
packages built from the same source (as defined in the deb's control
file) are made available before the checks (just as if they had been run
with their source)?
That is, if I run:
lintian A.deb B.deb A-data.deb B-data.deb
should lintian then do A + A-data and then B + B-data or just in
"whatever" order it feels like?
~Niels
[1] I.e. how is A.dsc B.dsc A.deb B.deb a better order than A.dsc A.deb
B.dsc B.deb?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNJRJCAAoJEAVLu599gGRCFigP/jfJYkzHrhJ9YTH+UwdcSDqd
MPutWhrm4RR6chUxWgOm8XgRLqBCWDsncC9Xe0U5hdpE3mAEXIWkxpXsyhGsx6G1
gp7OQHKwmP4IhfP9ej9fFcOVMx51XKjSAaGTJIk4yYhgPWU/7WlOzec0AzqWZXIu
uDEcBVLCNqvrI46I40+eizk71AbELQBbU8IAHHaCC0GVcyF/f1h41KL29E/wi7gJ
dtw98p5zCD2fqsMVRxdQREj+hFvEN+UygmMgVybjjQxiMk1jCteOFiBGkR6qEIBF
kj9MDl5DFUNrVUSliz3xy9AsRnyIEEOs9if8hBMsHzNA+f4AvAJt68F4skVm29eZ
TBRZZqDKyvpA7zn5y0qZBKekpM7A0XEl74aV33FnSrl5pEXaqO1tLkGVlimLg3Ue
EABTWuPmi+OSipbQ0T0HHtI9kFa5L4RI2ujs4ErMVhsy0zaHFudi433WV5CaqPrr
rQNq/Nc+wUFmwp3w/MtkaK7PSWLrx6SHeJt9Oz+eqU7+z0iVgPMzgvSr6nwN+KIb
goVmApMQGGUaEUQD6o2M18WG9TxyG1LGe0K59zC986GybMQrVXXs/dY9+TGj/s6S
6+PpMK9PSGD/ZA1mgttLik4CGYSqiGD2Pq66KH4XJUrAuNhTYet2DwSAX8+8kP48
lr6LGtqswWHvjw2wsAcx
=CrtA
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
