Re: binNMU for Arch: all packages.
Le 15/01/2011 18:22, Steve Langasek a écrit :
[...] and require us to use a hackish (= ), ( )
construction for all arch:any - arch:all dependencies just as we already
have to do for arch:all - arch:any dependencies.
This is as wrong as adding artificial versioned build-dependencies, as
is often the case when you are simulating a binNMU with a sourceful
upload in the middle of a transition.
Building manually the binNMUed arch:all package at the right time, and
uploading it would achieve a better result, IMHO. And then, all the
arch:any packages (if any) can be binNMUed on the buildds as usual, with
explicit dep-waits, without touching the source package.
One way to handle the substvar issue (which would be more correct to me)
is to add the possibility to specify a version constraint modulo binNMU.
So that Julien's example of [1] would look like:
Package: foo
Architecture: all
Package: bar
Architecture: any
Depends: foo (~= ${source:Version})
(if we choose ~= to denote version equality modulo binNMU). In terms of
implementation, it is conceptually similar to depending on a virtual
package that is provided by the corresponding binary with the same
source version.
[1] http://lists.debian.org/debian-devel/2011/01/msg00480.html
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d78f2f5.1000...@debian.org
Re: binNMU for Arch: all packages.
[Joachim Breitner, 2011-01-26] (I know that I’m not actually helping to solve the problem, but I want to give a better picture of the work involved and how much the buildd infrastructure is relied upon by the Haskell team – thanks for that!) FWIW: dh_python2 based packages would benefit from arch:all binNMUs as well (dh_python2 generates symlinks for all supported Python versions at build time instead of in preinst). That's not that big problem, though: Wheezy will most probably support Python 2.7 only which is the last Python 2.X version. Python 3.X do not have this problem anymore (thanks to Barry Warsaw's changes¹, some backported to python3.1 in Squeeze, to make Squeeze→Wheezy upgrade easy) [¹] PEP3147 and PEP3149 -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127093515.gq8...@piotro.eu
Re: binNMU for Arch: all packages.
Bastian Blank wa...@debian.org writes:
On Sat, Jan 15, 2011 at 01:23:01PM +0100, Julien Cristau wrote:
On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
Le 15/01/2011 11:29, Philipp Kern a écrit :
Arch:all binNMUing will only work if you keep the invariant of
version(arch:all) = version(source) in some way.
Why is this needed?
If ${source:Version} is not version(arch:all) you've got yourself an
uninstallable package. If ${source:Version} is not version(source)
things become slightly confusing.
Only if it is used. However the packages in question _don't_ have
versioned relations at all:
| Package: libghc6-zip-archive-doc
| Priority: extra
| Section: doc
| Installed-Size: 252
| Maintainer: Debian Haskell Group
pkg-haskell-maintain...@lists.alioth.debian.org
| Architecture: all
| Recommends: ghc6-doc
| Suggests: libghc6-zip-archive-dev
Again. We've had enough of that with
${Source-Version}. And it'll probably break some other stuff as well.
Well. Who spoke about a change of source:Version at all?
Bastian
Bringing up package relationships raises an interesting point.
If the generated docs don't work with different ghc versions then they
need to depend on the right ghc version, break the wrong version or ghc
needs to break them. I think the best would be a versioned provides
(when will they finally be usable?) like this:
Package: libghc6-zip-archive-doc
Provides: ghc6-docs (x.y)
Package: ghc6
Breaks: ghc6-docs ( x.y), ghc6-docs ( x.y)
But having some generated html files depend on the exact ghc version
seems extrem. So splitting out the version dependent .haddoc files into
the -dev packages (as mentioned in another mail in this thread) seems
the right, or at least the sanest, thing to do.
Am I right that with that split the -dev package depends on the right
ghc version (which is needs to anyway) while the -doc remains
independent? And with the -dev package being arch:any the whole issue of
arch:all binNMUs becomes mood?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5bz6bfo.fsf@frosties.localnet
Re: binNMU for Arch: all packages.
Hi Goswin. Excerpts from Goswin von Brederlow's message of Qua Jan 26 11:28:59 -0200 2011: (...) But having some generated html files depend on the exact ghc version seems extrem. Yes, I don't see the need of adding a Depends: field to -doc packages. So splitting out the version dependent .haddoc files into the -dev packages (as mentioned in another mail in this thread) seems the right, or at least the sanest, thing to do. This is the current approach, and it's not good, in my opinion, because it makes the index be created, with broken links. The .haddock file is used by ghc6-doc to know which packages should be listed in /usr/share/doc/ghc6-doc/html/libraries/index.html . If the -dev package is installed, but not the -doc, the links for the modules in this package are listed in this file, but they're broken. (...) And with the -dev package being arch:any the whole issue of arch:all binNMUs becomes mood? There are two issues. The first one is that the links in the index are not generated with old .haddock files. The other one is that new versions of haddock will produce different HTML files, and it's a good thing to have all documentation using the latest format haddock produces. I still think arch:all binNMU would be the exact solution, but I'm thinking about using sourceful uploads instead, since that seems to cause problems. Greetings. (...) signature.asc Description: PGP signature
Re: binNMU for Arch: all packages.
Marco Túlio Gontijo e Silva writes (Re: binNMU for Arch: all packages.): Excerpts from Goswin von Brederlow's message of Qua Jan 26 11:28:59 -0200 2011: (...) But having some generated html files depend on the exact ghc version seems extrem. Yes, I don't see the need of adding a Depends: field to -doc packages. More, it would be quite wrong because it makes perfect sense to install _just_ the documentation. If you think having the programs of one version and the docs of a different version installed is too badly confusing, then the programs could declare Breaks against the other docs versions. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19776.20754.886051.771...@chiark.greenend.org.uk
Re: binNMU for Arch: all packages.
Marco Túlio Gontijo e Silva mar...@debian.org writes: Hi Goswin. Excerpts from Goswin von Brederlow's message of Qua Jan 26 11:28:59 -0200 2011: (...) But having some generated html files depend on the exact ghc version seems extrem. Yes, I don't see the need of adding a Depends: field to -doc packages. So splitting out the version dependent .haddoc files into the -dev packages (as mentioned in another mail in this thread) seems the right, or at least the sanest, thing to do. This is the current approach, and it's not good, in my opinion, because it makes the index be created, with broken links. The .haddock file is used by ghc6-doc to know which packages should be listed in /usr/share/doc/ghc6-doc/html/libraries/index.html . If the -dev package is installed, but not the -doc, the links for the modules in this package are listed in this file, but they're broken. Then have -dev recommend -doc. Then users get the docs installed by default and have woking links and autobuilders don't. Or put the .haddock file somewhere private where ghc6-doc doesn't see it and put a link into the -doc package that ghc6-doc does see. Then -doc has to depend on -dev. (...) And with the -dev package being arch:any the whole issue of arch:all binNMUs becomes mood? There are two issues. The first one is that the links in the index are not generated with old .haddock files. The other one is that new versions of haddock will produce different HTML files, and it's a good thing to have all documentation using the latest format haddock produces. I'm hoping the haddock output does not change drsatically on every upload. On updates where it changes a full sourcefull upload can be done or arch:all binNMUs. But that would be a rare(r) occurance. I still think arch:all binNMU would be the exact solution, but I'm thinking about using sourceful uploads instead, since that seems to cause problems. In a perfect world ... Greetings. (...) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwsfmvn8.fsf@frosties.localnet
Re: binNMU for Arch: all packages.
Hi, Am Samstag, den 15.01.2011, 10:29 + schrieb Philipp Kern: On 2011-01-15, Marco Túlio Gontijo e Silva mar...@debian.org wrote: The best option to fix this issue I can see is if it was possible to do binNMUs for Arch: all packages. There are some options to workaround the fact that we can't binNMUs Arch: all packages, which are: change the -doc package to Arch: any; do sourceful uploads instead of binNMUs. Both options are not ideal, but I prefer the first, because sourceful uploads for a 200 package stack would need a lot of work. If the packages are team-maintained, nothing is stopping you from bumping the revision with dch and do a build, sign, upload cycle. Indeed without source-only uploads you need to build it once. But that's scriptable. (And you can even cache the key's passphrase through gpg-agent.) it would be ok if we were allowed to do dch; dpkg-buildpackage -d -S; debrelease. But actually building these 200 package manually on ones own workmachine, getting the order of building correct, installing dependencies and so on, without actually changing the package and just so that they are rebuild is quite a nuisance and thus a slight waste of developer resources and motivation. The buildds handle this much better due to BD-Uninstallable and not blocking someones’s laptop. And if there were autosigning in place (it is not yet, right?), the amount of human time required would drop to almost zero. (I know that I’m not actually helping to solve the problem, but I want to give a better picture of the work involved and how much the buildd infrastructure is relied upon by the Haskell team – thanks for that!) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: binNMU for Arch: all packages.
On 2011-01-15, Marco Túlio Gontijo e Silva mar...@debian.org wrote: The best option to fix this issue I can see is if it was possible to do binNMUs for Arch: all packages. There are some options to workaround the fact that we can't binNMUs Arch: all packages, which are: change the -doc package to Arch: any; do sourceful uploads instead of binNMUs. Both options are not ideal, but I prefer the first, because sourceful uploads for a 200 package stack would need a lot of work. If the packages are team-maintained, nothing is stopping you from bumping the revision with dch and do a build, sign, upload cycle. Indeed without source-only uploads you need to build it once. But that's scriptable. (And you can even cache the key's passphrase through gpg-agent.) Arch:all binNMUing will only work if you keep the invariant of version(arch:all) = version(source) in some way. IMHO sourceful uploading is the way to go, however, it's frown upon because those are in fact NMUs for packages you don't own. For Haskell that shouldn't be a problem, for others we might like to carve out a policy. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnij2toq.ol6.tr...@kelgar.0x539.de
Re: binNMU for Arch: all packages.
Le 15/01/2011 11:29, Philipp Kern a écrit : Arch:all binNMUing will only work if you keep the invariant of version(arch:all) = version(source) in some way. Why is this needed? -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d318350.8030...@debian.org
Re: binNMU for Arch: all packages.
On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
Le 15/01/2011 11:29, Philipp Kern a écrit :
Arch:all binNMUing will only work if you keep the invariant of
version(arch:all) = version(source) in some way.
Why is this needed?
Package: foo
Architecture: all
Package: bar
Architecture: any
Depends: foo (= ${source:Version})
If ${source:Version} is not version(arch:all) you've got yourself an
uninstallable package. If ${source:Version} is not version(source)
things become slightly confusing. Again. We've had enough of that with
${Source-Version}. And it'll probably break some other stuff as well.
Cheers,
Julien
signature.asc
Description: Digital signature
Re: binNMU for Arch: all packages.
On Sat, Jan 15, 2011 at 01:23:01PM +0100, Julien Cristau wrote:
On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
Le 15/01/2011 11:29, Philipp Kern a écrit :
Arch:all binNMUing will only work if you keep the invariant of
version(arch:all) = version(source) in some way.
Why is this needed?
If ${source:Version} is not version(arch:all) you've got yourself an
uninstallable package. If ${source:Version} is not version(source)
things become slightly confusing.
Only if it is used. However the packages in question _don't_ have
versioned relations at all:
| Package: libghc6-zip-archive-doc
| Priority: extra
| Section: doc
| Installed-Size: 252
| Maintainer: Debian Haskell Group
pkg-haskell-maintain...@lists.alioth.debian.org
| Architecture: all
| Recommends: ghc6-doc
| Suggests: libghc6-zip-archive-dev
Again. We've had enough of that with
${Source-Version}. And it'll probably break some other stuff as well.
Well. Who spoke about a change of source:Version at all?
Bastian
--
Killing is wrong.
-- Losira, That Which Survives, stardate unknown
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110115125206.ga19...@wavehammer.waldi.eu.org
Re: binNMU for Arch: all packages.
On Sat, Jan 15, 2011 at 10:29:46AM +, Philipp Kern wrote: Arch:all binNMUing will only work if you keep the invariant of version(arch:all) = version(source) in some way. This invariant comes from where? From my knowledge neither w-b nor dak cares about it. Bastian -- Deflector shields just came on, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110115125334.gb19...@wavehammer.waldi.eu.org
Re: binNMU for Arch: all packages.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2011-01-14 22:22, Yves-Alexis Perez wrote: On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote: This documentation is generated automatically from the source code, using a documentation generator called haddock. Haddock is part of the compiler and is also updated when the ghc is. It would be good to regenerate the documentation for each library too, when a new ghc arrives. I don't really know anything about haskell, but is it really needed to regenerate library docs each time the compiler is updated? What does it give? Hey, It is possible the Java packages could use binNMU for arch: all packages as well. There was some talk about injecting ABI versioning in Java Libraries at DebConf10, so we could handle ABI breakage in a similar way to how it is done with regular libraries. ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNMZp0AAoJEAVLu599gGRCG9AQAIkbZm70clVfWLOhqy12zZgC EEytgjw9d8twNbY5kib+xWxGzOT7I/4LrC0ayoF5+VacYmgAhlBydoarHK1oJvyw ExAxfYiADLKwoxsoFHZNlbBCEkoLYnx8sdmg/Yu6CVVeNtp+xwKCfk9QLGBSieJw nzTDsd5+GTJrgH6FGW3RVwC7XQqhuGKVD34BxHnO3SqQiFjbiMgSxkU9qa3Vb5rp G8qSm4oRm94B8k4DU920WgcjdISAY/ZnlILwYwsOjx5DFr5fEQjXTsIHEc9dad4S +WZPOS2YkXdXbHOrS5c9rGJICHtjdcThRofr6onllOoBM8zbeU3B3Fexwf6Unm9v 0N/KpoTN787yfE78HJBOdOBTXQFGqtX4qvRvl2ZpXmULga5kZgjvu9Rrgf2+d5Ki /31Fc8eSzNsFRV5/FDLXdQ55ak98m+Fh5s0tVtD0oCs9hXxWWE8tl1FN/Z42/+y1 XNyuzkGhTPYRPCAubeCOGWX1yvIAwVino+CEQpWDeRzeJCTixng5V+JH+iwOZWIQ VIwEIyj4TkbkK0fLycjzXMuelXmvAteZ6ANcOtGMYRTD99hCInKXPfu98vfu/4u0 ec01EIDphzcbpBoDwU9Qz4K/r7SDrThZpsHvesZnCYSYgs4/UuSv0rsHhfNKnRob saOk9gZyM0BaVUhiBDTQ =/CL/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d319a75.3080...@thykier.net
Re: binNMU for Arch: all packages.
On Sat, Jan 15, 2011 at 13:52:06 +0100, Bastian Blank wrote:
On Sat, Jan 15, 2011 at 01:23:01PM +0100, Julien Cristau wrote:
On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
Le 15/01/2011 11:29, Philipp Kern a écrit :
Arch:all binNMUing will only work if you keep the invariant of
version(arch:all) = version(source) in some way.
Why is this needed?
If ${source:Version} is not version(arch:all) you've got yourself an
uninstallable package. If ${source:Version} is not version(source)
things become slightly confusing.
Only if it is used. However the packages in question _don't_ have
versioned relations at all:
I don't think it's reasonable to say arch:all binnmus are allowed for
$this_set_of_packages, but not for the rest. So what this particular
set of packages does is irrelevant, as far as I'm concerned.
Cheers,
Julien
signature.asc
Description: Digital signature
Re: binNMU for Arch: all packages.
Le 15/01/2011 13:23, Julien Cristau a écrit :
Package: foo
Architecture: all
Package: bar
Architecture: any
Depends: foo (= ${source:Version})
If ${source:Version} is not version(arch:all) you've got yourself an
uninstallable package. If ${source:Version} is not version(source)
things become slightly confusing. Again. We've had enough of that with
${Source-Version}. And it'll probably break some other stuff as well.
Well... Someone could also make an arch:any package depend on the
${source:Version} of another arch:any package, if he wants to shoot
hisself in the foot. It doesn't prevents binNMUs of arch:any packages.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d31f558.3040...@debian.org
Re: binNMU for Arch: all packages.
On 2011-01-15, Stéphane Glondu glo...@debian.org wrote:
Le 15/01/2011 13:23, Julien Cristau a écrit :
Package: foo
Architecture: all
Package: bar
Architecture: any
Depends: foo (= ${source:Version})
If ${source:Version} is not version(arch:all) you've got yourself an
uninstallable package. If ${source:Version} is not version(source)
things become slightly confusing. Again. We've had enough of that with
${Source-Version}. And it'll probably break some other stuff as well.
Well... Someone could also make an arch:any package depend on the
${source:Version} of another arch:any package, if he wants to shoot
hisself in the foot. It doesn't prevents binNMUs of arch:any packages.
You do realize that it's common to do the source:Version dependency stuff in
arch:all packages, right? That kind of polemics you just raised doesn't seem
helpful to me.
Kind regards
Philipp Kern
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnij3vf5.pfk.tr...@kelgar.0x539.de
Re: binNMU for Arch: all packages.
On Sat, Jan 15, 2011 at 01:53:34PM +0100, Bastian Blank wrote:
On Sat, Jan 15, 2011 at 10:29:46AM +, Philipp Kern wrote:
Arch:all binNMUing will only work if you keep the invariant of
version(arch:all) = version(source) in some way.
This invariant comes from where? From my knowledge neither w-b nor dak
cares about it.
From the de facto policy that was designed when binNMUs became common
practice, to ensure that we had a usable, binNMU-safe scheme to replace the
prior (= ${Source-Version}) usage.
Permitting arch: all binNMUs will break the assumption underlying all (=
${source:Version}) dependency declarations in use across all our packages,
making them instantly buggy, and require us to use a hackish (= ), ( )
construction for all arch:any - arch:all dependencies just as we already
have to do for arch:all - arch:any dependencies.
I agree that it's far preferable to do source NMUs in these cases.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: binNMU for Arch: all packages.
On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote: This documentation is generated automatically from the source code, using a documentation generator called haddock. Haddock is part of the compiler and is also updated when the ghc is. It would be good to regenerate the documentation for each library too, when a new ghc arrives. I don't really know anything about haskell, but is it really needed to regenerate library docs each time the compiler is updated? What does it give? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: binNMU for Arch: all packages.
Hi Yves-Alexis. Excerpts from Yves-Alexis Perez's message of Sex Jan 14 19:22:31 -0200 2011: On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote: This documentation is generated automatically from the source code, using a documentation generator called haddock. Haddock is part of the compiler and is also updated when the ghc is. It would be good to regenerate the documentation for each library too, when a new ghc arrives. I don't really know anything about haskell, but is it really needed to regenerate library docs each time the compiler is updated? Yes, in the current scheme, unfortunately it is. What does it give? There are two issues. The first one is related to the indexer. Whenever a new haskell package is installed, there's a code that includes the modules that it export in the main index of the documentation. If the version of haddock installed is different from the version of haddock that produced the documentation being installed, it won't show this package in the main index. This happens because when the compiler is updated, the representation of the Haskell code changes, and this affects haddock. It is possible to deal with this issue by changing the way the index is generated. But the other issue is that sometimes the haddock version changes during compiler updates, and the documentation produced change very much. For instance, [0] was the documentation produced in ghc-6.12.3, and [1] is the documentation produced in ghc-7.0.1. I believe it's better for the user to have access to all features and bug fixes of newer haddock, instead of sticking with older haddock versions to avoid recompilation. Currently, we move the .haddock file to -dev packages (which are Arch: any) in order to avoid the first issue. This causes [2]. Also, it makes the whole documentation be generated when a -dev package is built, so it's already generated in all arches, only ignored. The best option to fix this issue I can see is if it was possible to do binNMUs for Arch: all packages. There are some options to workaround the fact that we can't binNMUs Arch: all packages, which are: change the -doc package to Arch: any; do sourceful uploads instead of binNMUs. Both options are not ideal, but I prefer the first, because sourceful uploads for a 200 package stack would need a lot of work. I talked about this issue on #debian-devel and mrvn asked me to change the wanna-build / buildd / sbuild interface to accept this. Well, I have no idea about how to do it, since I've never worked on these packages, but if this is something the developers of these package are willing to accept, I could help on the implementation. Thanks for your answer. 0: http://haskell.org/ghc/docs/6.12.3/html/libraries/index.html 1: http://haskell.org/ghc/docs/7.0.1/html/libraries/index.html 2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586723 -- marcot http://marcot.eti.br/ [Flattr=54498] signature.asc Description: PGP signature
