Re: Unblock of packages in could be handled by britney
On Sat, Apr 05, 2008 at 01:46:54PM +0200, Frans Pop wrote: Status is: I personally think we'll need to address this at some point but it has never really been discussed within the team and I've no idea what will be involved other than that it's likely to be invasive. In other words: there is no status. Feelings shared here. Maybe we could think of this as one of the first issue to tackle after Lenny has been released, but I really think that it is too late to change the current mechanisms if we want a working installer for Lenny within the current schedule. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Re: Unblock of packages in could be handled by britney
On Sat, Apr 05, 2008 at 07:25:15AM +0200, Frans Pop wrote: On Friday 04 April 2008, Frans Pop wrote: Note that this still only one reason why we need the acks. Preventing breakage is the other. Actually, the current klibc migration is a very nice example of this, so let me elaborate. I hope this extended example demonstrates sufficiently why I feel that all migrations of udebs should be acked by the D-I RM. And that it also demonstrated that the category could be handled by britney is a bit more complex than the name implies. It does demonstrate that proper dependency support for udebs should be added... If proper britney support was implemented there _are_ some udebs that could be done completely automatically, but there will always be cases where automated checks are insufficient. At least until we completely rework the dependency declarations in udebs (which would also require adding support for Conflicts). What is the status of this reworked udeb dependency handling? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unblock of packages in could be handled by britney
(No need to CC me: I read both lists) On Saturday 05 April 2008, Luk Claes wrote: If proper britney support was implemented there _are_ some udebs that could be done completely automatically, but there will always be cases where automated checks are insufficient. At least until we completely rework the dependency declarations in udebs (which would also require adding support for Conflicts). What is the status of this reworked udeb dependency handling? Status is: I personally think we'll need to address this at some point but it has never really been discussed within the team and I've no idea what will be involved other than that it's likely to be invasive. In other words: there is no status. Please remember that before Etch library dependencies were not even correctly generated (dh_shlibdeps would return regular packages instead of udebs). This is currently still the case for glibc, but hopefully not for long as I filed a BR (with patch) yesterday to fix that. Unfortunately this whole aspect seems to have been underestimated when udebs were first defined. Or maybe it's not so much underestimation, but just the fact that D-I's scope has grown in such a way that this is just more of an issue then it was in the beginning. The only thing we can do here is take this in steps. The next step should be britney support within the limits of the current situation regarding udeb dependencies. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Unblock of packages in could be handled by britney
On Thursday 03 April 2008, Philipp Kern wrote: On Thu, Apr 03, 2008 at 03:42:31PM +0200, Frans Pop wrote: It started with a request from maks to unblock mklibs which phil acted on without waiting for an OK from a D-I RM. klibc, not mklibs. Yes, sorry. Let me also note that my intention or IRC was never to say that klibc should not migrate to testing, but just that it (or any other package producing udebs) should not be hinted without at the very least making sure that the D-I RM was aware of it. There are basically two reasons for blocking udebs by default: - avoiding breaking the current release of the installer - avoiding that udebs in testing are out of sync with the source version Fact of life is that ATM udebs need to be synced manually after a package migrates and that the D-I RM is the person who coordinates that, so even if a package is safe to migrate, he needs to know about it and the best way to achieve that is by having him ack hints explicitly. I fully agree that the whole procedure is far from optimal and could be improved, but that just is how things are currently. I still hope that someone will implement my proposal for adding support for udebs in britney as that would - get rid of the manual syncing of udebs and thus ensure that we can no longer find ourselves in the situation that a sync was forgotten or done too late and that the udebs no longer exist and we have to wait for the next upload to be ready for migration; - allow at least some package to migrate with only regular dependency checks. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Unblock of packages in could be handled by britney
On Fri, Apr 04, 2008 at 09:22:32AM +0200, Frans Pop wrote: Fact of life is that ATM udebs need to be synced manually after a package migrates and that the D-I RM is the person who coordinates that, so even if a package is safe to migrate, he needs to know about it and the best way to achieve that is by having him ack hints explicitly. Now if that is the point you could also compile a list of out-of-sync udebs. Isn't this already being done by Jeroen in an automatic way? Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Debian Release Assistant `. `' xmpp:[EMAIL PROTECTED] `-finger pkern/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unblock of packages in could be handled by britney
On Friday 04 April 2008, Philipp Kern wrote: On Fri, Apr 04, 2008 at 09:22:32AM +0200, Frans Pop wrote: Fact of life is that ATM udebs need to be synced manually after a package migrates and that the D-I RM is the person who coordinates that, so even if a package is safe to migrate, he needs to know about it and the best way to achieve that is by having him ack hints explicitly. Now if that is the point you could also compile a list of out-of-sync udebs. Isn't this already being done by Jeroen in an automatic way? The list exists. What's not automated is someone watching it and actually doing the migrations. The acks help us to know _when_ there are changes. Note that this still only one reason why we need the acks. Preventing breakage is the other. signature.asc Description: This is a digitally signed message part.
Re: Unblock of packages in could be handled by britney
On Friday 04 April 2008, Frans Pop wrote: Note that this still only one reason why we need the acks. Preventing breakage is the other. Actually, the current klibc migration is a very nice example of this, so let me elaborate. Yesterday we had the following message and commit: http://lists.debian.org/debian-boot/2008/04/msg00112.html http://svn.debian.org/wsvn/d-i/trunk/packages/rootskel/?rev=52409sc=0 Note that the dependency was undeclared (a minor bug) and is now still unversioned (as I don't know the reasons I cannot explain them), so ensuring rootskel and klibc are kept in sync needs to be done manually. So, rootskel and klibc should migrate together. That means we need to look at other changes in rootskel. rootskel 1.59 includes changes required for D-I to work with busybox 1.9.1-3, but those changes will break with older versions of busybox (again this dependency is not declared, just noted in the changelog), so that ties busybox together with rootskel and klibc. Let's look at busybox 1.9.1-3. That dropped the ifconfig command in favor of the ip command. We still had a few components that used ifconfig (network-console, installation-report and ppp-udeb), so those should all migrate together with busybox; in this case the new versions will also work with the old busybox. But ppp-udeb has not yet been updated. There's also a mild regression in busybox 1.9.1-3 for the pidof command (#472846) for which a workaround was added in finish-install, so add that in the mix. Now, luckily currently all these 4 components don't have changes that require additional updates, so it ends here. Note that in all these cases the dependencies are undeclared and that both busybox and klibc are in the could be handled by britney class. So, why did we not object to the migration of klibc? - it does not break the current release of D-I because both klibc and rootskel are included in D-I initrds at build time - we don't do new builds of D-I based on Lenny, except for new releases - there probably are others who _do_ build D-I based on Lenny, but as this only affects floppy-based installations and migrating klibc is way more important than that, we allow it anyway; it's a trade-off The same goes for migrating busybox: it's always included in D-I initrds, so migrating only busybox will not break the current D-I release. However, in this case the breakage for new builds is much more severe (as it affects all installation methods, not just floppy installs), so we probably _will_ want to migrate the related D-I components to Lenny at the same time. I hope this extended example demonstrates sufficiently why I feel that all migrations of udebs should be acked by the D-I RM. And that it also demonstrated that the category could be handled by britney is a bit more complex than the name implies. If proper britney support was implemented there _are_ some udebs that could be done completely automatically, but there will always be cases where automated checks are insufficient. At least until we completely rework the dependency declarations in udebs (which would also require adding support for Conflicts). Cheers, FJP signature.asc Description: This is a digitally signed message part.
Unblock of packages in could be handled by britney
[ Ob: Please keep this discussion on at least d-release ] Hi there, today members of the Release Team wondered on IRC about when to unblock udebs in the could be handled by britney section of the freeze hints file while not being in any d-i beta freezes. Otavio suggested that they could be handled just like normal packages (i.e. unblocked on request) and do not need explicit approvals. But we had differing opinions on #d-release. So what are we allowed to do, or not to do with relation to this set of packages? Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Debian Release Assistant `. `' xmpp:[EMAIL PROTECTED] `-finger pkern/[EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Unblock of packages in could be handled by britney
On Thursday 03 April 2008, Philipp Kern wrote: today members of the Release Team wondered on IRC about when to unblock udebs in the could be handled by britney section of the freeze hints file while not being in any d-i beta freezes. For those who did not see the discussion on IRC, here's the log (note that this is a selection, not the full log). It started with a request from maks to unblock mklibs which phil acted on without waiting for an OK from a D-I RM. Cheers, FJP fjp maks: Because RMs don't have the knowledge needed to decide udeb unblocks and there's the need to get the udeb syncs done in time. fjp We can ease up on this for some packages if my britney proposal would get implemented, but not until that happens. jcristau i thought only some udebs needed a d-i ack? at least that's what the comments in ftp-master/testing/hints/freeze suggest... aba fjp: AFAIUI, we can unblock packages in the first section always fjp aba: No, you cannot. aba fjp: since when? phil fjp: Then please elaborate why not. fjp aba: Since always. aba fjp: that's not correct. fjp OK, this has been explained before, but apparently needs explaining again. fjp aba: It is correct. We only made an exception for the period when there was no Beta release. fjp The reasons are: fjp - if a udeb migrates without the D-I RM knowing about it, there is a big chance that the udebs will not be synced in time fjp - there is no dependency checking for udebs, so that needs to be done manually fjp - udebs that are not included in the initrd but loaded later can break the current D-I release if they contain incompatible changes fjp That also includes udebs from packages in the first section. fjp The reason it says could be handled by Britney assumes that Britney would do depency checking. fjp So, approving packages with udebs without doing the dependency checking is broken, even for components in the first section. HE So if the Release team handles udeb sync requests and checks dep, we can unblock the packages from the first section without ACKs from you, right? fjp That is why we ask you to wait for an ack from D-I RM. phil And d-i RMs are doing this dep check manually everytime? Using a tool? fjp phil: Generally we just know, based on deeper knowledge of relationships between components, whether or not a migration is safe. phil klibc looks selfcontained so there can't be broken deps? fjp HE: The first requires FTP-master; dependency checking is a bit more involved that just pure explicitly declared deps. fjp phil: Did you check that before you added the hint? fjp Please see my proposal for udeb migration handling. It's all in there. HE fjp: If it's too complex for a human, I don't see how britney could do it. Or you, for that matter. phil fjp: I checked the changes which did not announce an ABI change or something, but well, probably not enough then. fjp HE: Don't you think that it's possible D-I RMs know just a bit more about D-I internals than other DDs? HE fjp: I believe that, what I don't think is that you are crazy enough to say that the information is not all written down somewhere, but britney would be able to check it HE fjp: As long as you point out that a britney change can do it, I assume that manual from by the release team can do as well. jcristau fjp: isn't that true for any other package? yet other DDs can check deps. fjp HE: See my proposal. I'm not saying that Britney could check it all. fjp Even with implememtation in Britney, my proposal still has blocks by default for a lot of components. HE Yeah, but we were talking about those udebs you are willing to leave to britney. fjp However, some packages, including klibc, could then be handled automaticalyly. fjp HE: That list does not completely match the first section. fjp jcristau: Depends has a different meaning for udebs than it has for debs. fjp Yes, that is somewhat broken, but it's the way it was implemented way back. fjp The main point here is that there are complicating factors of which I don't expect everybody to be aware, but that is the main reason behind the request to not migrate packages with udebs without D-I approval. fjp And that's generally worked perfectly for the Etch lifetime. HE So, to sum it up: You would be willing to let some things done automatically by britney, but don't want the release team to do it manually, because we don't have the information available that would be available to britney. And until that changes, we will need get an ACK from you for every single package at the base of the dependency tree, as those usually provide udebs. Yay. fjp HE: That's not completely correct. Please read my proposal. fjp http://lists.debian.org/debian-release/2007/05/msg00086.html *fjp really wishes someone would implement that HE fjp: I read your proposal, twice actually. Besides being a proposal (and thus, not a solution), it does not point out why the release team isn't able to do something manually that a tool
Re: Unblock of packages in could be handled by britney
On Thu, Apr 03, 2008 at 03:42:31PM +0200, Frans Pop wrote: It started with a request from maks to unblock mklibs which phil acted on without waiting for an OK from a D-I RM. klibc, not mklibs. Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Debian Release Assistant `. `' xmpp:[EMAIL PROTECTED] `-finger pkern/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
