> > But I still do not understand, why some cabal files are patched, and > > other are replaced as whole. How could it be, that file in > > additional-cabals/ is not present in 01-index.tar? > > We base our packaging of Haskell package on the “pristine” tarball on > Hackage, with the revision 0 .cabal file. > > The patches, which also live in the Debian packages, thus need to apply > to the pristine tarball. > > We want the same patches to work in the actual Debian package, and in > the package-plan. > > But the 01-index.tar may contain updated cabal files (e.g. revision 1). > If we would use that, then the patch would not apply cleanly. > > Therefore, we add the revision 0 cabal file to additional-cabals/, to > override what’s in 01-index.tar. This recreates the situation in the > Debian package, and allows the patch to apply cleanly. > > Also, I believe it is possible to generate this additional-cabal/ and > > patches/ directories automatically, but for this I need to comperhand > > how they were created manually. > > What would you create it from? But yeah, more automation might be > possible! If I understand things correctly, we download whole 01-index.tar, containing cabal files for all packages from history of Haskell? (~250k files) Would not it be more efficent to download only cabal files for packages we are concerned with? Here is the plan: * Get master snapshot of DHG_packages * Scan `packages.txt', and extract its cabal file from from snapshot, if it there, or download from hackage (rev 0) if it is a new package. * Cast black magic to download cabal files of packages, that are distributed with GHC This way we reduce * number of packages to consider for resolver from 250k to ~1k * bandwidth requirements for fresh installation (e.g Jenkins) * time needed to perform check Did I miss something? === Top-posting for sake of list. Sorry === [2018-09-16 22:03] Joachim Breitner <nomeata@debian.org> > is there a reason this is off list? If not, please add debian-haskell > in your reply. > > Am Sonntag, den 16.09.2018, 22:28 +0300 schrieb KAction@gnu.org: > > I am considering, what can be done to speed-up 'test-packages.pl' > > script. Right now it performs multiple of linear search in 500Mb tar > > archive during applying patches, which is not fast. I reimplemented > > this procedure in C [1], which promises improved perfomance. > > Great! > > > But I still do not understand, why some cabal files are patched, and > > other are replaced as whole. How could it be, that file in > > additional-cabals/ is not present in 01-index.tar? > > We base our packaging of Haskell package on the “pristine” tarball on > Hackage, with the revision 0 .cabal file. > > The patches, which also live in the Debian packages, thus need to apply > to the pristine tarball. > > We want the same patches to work in the actual Debian package, and in > the package-plan. > > But the 01-index.tar may contain updated cabal files (e.g. revision 1). > If we would use that, then the patch would not apply cleanly. > > Therefore, we add the revision 0 cabal file to additional-cabals/, to > override what’s in 01-index.tar. This recreates the situation in the > Debian package, and allows the patch to apply cleanly. > > > > > Also, I believe it is possible to generate this additional-cabal/ and > > patches/ directories automatically, but for this I need to comperhand > > how they were created manually. > > What would you create it from? But yeah, more automation might be > possible! > > Joachim
Attachment:
pgpHo8bPIrS0i.pgp
Description: PGP signature