Hi Kaol, hi others, Am Mittwoch, den 21.01.2009, 07:09 +0200 schrieb Kari Pahula: > > > A goal I'd like to push for, regarding haskell libraries: > > I'll still have to read and think about this fully. But I can name > one concern already... > > > I already introduced the idea of using a hash of the interfaces hashes > > in the .hi files in the package to automatically, with > > haskell-devscripts, provide a > > > Provides: libghc6-mtl-dev-1.1.0.2-ABCDEF012345679 > > I don't think that polluting dpkg's namespace like that is a good > idea. Treat it as a scarce resource. Those names are bound to left > lying around for a time and soon there's going to be thousands of > those. I think aptitude is slow enough as it is. > > This would inevitably raise things that don't concern people not using > Haskell to their eyes. I don't like that. > > Not to mention that this usage of Provides is contrary to what Policy > 3.6 describes. It's meant for cases when there are several real > packages providing a similar functionality. Your proposal gets this > backwards. this is a valid point, especially if dpkg’s garbage-collector is bad. Too bad that versioned provides[1], something in the queue since 10 years, is not implemented yet. So I thought more about this, and here are some alternatives: * so-name-line handling Our ABI hash is technically the same as a soname for a C shared library, right? For these, it’s common procedure to embed the soname in the binary package name directly. This would have similar pros and cons as proposal with Provides, but differs in this way: - Name has to be written in debian/control before building. This means more work, it requires the package to be built on the same arch as the last time, as (presumably) the .hi files differ across arches. - Uploads have to go through new - dpkg name space is still polluted, but this time in a way that has precedent. Actually, using this argument, one might get away with the Provides-variant – policy is not set in stone, and if the advantages (less work on buildds) outweigh this issue, it might still be an viable option. * Twofold Debian revision One can make the Debian revision of the form "-1.1", where the first number is incremented on an upload that changed the ABI, and the second on an upload that didn’t change it. The haskell-devscripts would then add appropriate Depends (>= ...-1) and (<< ...-1+). This has the same disadvantage as it’s fixed across all arches, that it needs manual intervention when building and that it’s easily forgotten. * Hoping for the best The simplest approach would be to assume that most uploads of the same cabal version will not change the ABI, and do not technically cater for that. Dependencies are are of the form (>= 1.2.3-3) and (<< 1.3.3+), assuming 1.2.3-3 was the current version. When an upload actually does break the ABI, one manually notices (because of bugreports, or maybe by some tool that checks this regularly and notifies the maintainers), one requests binNMUs against the depending packages. I still find the Provides:-idea most elegant, especially as it will gracefully handle the case where the ABI does not change on the uploaders machine, but on some other arch (maybe a bit far-fetched, but still...). Also, besides maybe the ftp-masters, there won’t be many non-haskellers noticing, I hope. For example http://packages.debian.org/unstable/virtual/ does not seem to work anyways :-) I could try to get some statements from debian-dpkg@l.d.o – unless you there are major other issues with the Provides:-approach that make that unlikely anyways. Greetings, Joachim [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=134582 and lots of merged ones -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil