Re: Triggers status?
On Wed, 31 Oct 2007, Guillem Jover wrote: If this was about fixing only log entries, there's several ways to accomplish that that imply zero conflict resolution while merging, 'git commit --amend', 'git format-patch' and editing the resulting mails, 'git cherry-pick -n', the more advanced 'git-filter-branch', etc. In general mostly yes, but it's not really true in the case of Ian's dpkg.triggers dpkg.speedup branch, see the tries that I did in [EMAIL PROTECTED]. That's because Ian based his speedup branch on his triggers branch and made several changes to the same area of code in both branches. That is if you rewrite history, you loose the merge information and you'll get some conflicts on those area (but they are trivial to fix for the one who has written the code). (That said, if you rewrite history on the parent branch, you should also rewrite it in the child branch) My only suggestions for the future are: 1/ Avoid implementing new features on top of an unmerged branch (if possible) 2/ If it's required, make sure that the unmerged branch is clean and ready to be merged 3/ Don't fear conflicts, they're not the root of all evil and git makes it easy to resolve them (and git-rerere helps you there to avoid resolving multiple times the same conflict, in case you rewrite the history multiple times) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Triggers status
FYI, I have (thanks to help from Raphael) published all my branches on Alioth. You can find them here: http://git.debian.org/?p=users/iwj/dpkg.git git://git.debian.org/git/users/iwj/dpkg.git The triggers branch is the ref called `triggers' there. Likewise `speedup' is my experimental flex based parser. This version should be used for merging as it is the most up to date. In particular, while sorting out #432893 I found a small bug whose fix I have cherrypicked onto the triggers branch. I'm going to leave the trees on www.chiark for now but they will disappear at some point, without any particular future warning. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Wed, 2007-10-24 at 22:35:23 +0100, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): * you replaced a bunch of NULL by (char*)0. This reverts http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e I believe you should use NULL everywhere. (My personal taste also favors NULL over (char*)0 but it's not even a question of what I prefer since I'm not an official dpkg maintainer) This isn't a matter of preference, I'm afraid. I reverted this because the change was wrong. NULL is incorrect in that context (a stdarg function expecting a char*), because it may be #define'd to 0. That's true, but then I agree with others [0] that an environment that defines NULL to 0 (even if the standard allows that) is not sane. Such ancient environment will also not be able to cope with modern software like gtk, anyway. regards, guillem [0] http://lwn.net/Articles/93577/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Thu, 2007-10-25 at 16:30:24 +0100, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): And it would be wise fine to proceed that way if your history was clean and all. I was just showing you that loosing the history doesn't involve as much work as you expected to, but of course it's more work. I don't know what you mean by `not as much as you expected'. The results you demonstrated seemed entirely consistent with what I expected and it is precisely that kind of merging makework that my approach avoids. Doing extra merge work for the benefit of cosmetic redaction of commit logs (which is IMO itself of doubtful value) seems an absurd tradeoff. Merging substantial conflicting changes is one of the most demanding and error-prone programming tasks. I'm astonished that you're seriously advocating a workflow that prefers to have humans running around fixing up mistakes made by computers. If this was about fixing only log entries, there's several ways to accomplish that that imply zero conflict resolution while merging, 'git commit --amend', 'git format-patch' and editing the resulting mails, 'git cherry-pick -n', the more advanced 'git-filter-branch', etc. Guillem, do you have an opinion about the use of git I'd like to see the changes split in logical patches/commits, with proper log messages. It makes the review task easier, but more importantly it makes the history in the main repo clearer, for people to dig into if needed in the future, or in the present, via the debian-dpkg-cvs mailing list, which is how the other part of the peer review is done right now. The fact that those changes are in a branch is no excuse to treat them in a different way in which they would be treated if submitted as incremental patches. To git this distinction is not meaningful; push, pull, format-patch, etc, are just ways to transfer the changes. It might also be easier for you to not make new changes dependant on some of your existing branches, to avoid unneeded conflicts and also this way merging them into the main repo should be easier. I also get the impression that your current workflow and derived complaints stem from a lack of familiarity with git and its commands and possible workflows, which should allow you to do less manual work and not more! I think there's enough people here that can (and might be willing to) help with specific issues. or (preferably!) about the actual code ? I've not yet properly reviewed it, just skimmed over the changes some weeks ago, and found some of the problems Raphael described. I'd like to finish the current release and then I'll focus on the triggers stuff. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Mon, 2007-10-22 at 17:45:43 +0100, Ian Jackson wrote: Oops, unfinished paragraph: Ian Jackson writes (Re: Triggers status?): Guillem: in a spirit of trying to have better cooperation, can I ask that you if you feel you need to review these changes in detail you do so reasonably promptly, and get back to me with your comments. I promise to try to engage constructively with the substance of any criticisms you have and to make any changes that we agree. If we cannot agree I suggest that we seek consensus here on this list. Sure! As I've said on another mail, let's finish the current release and then I'll get to it. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Kurt Roeckx wrote: I think you're talking about an implementations of stdargs here, not what the standards says should happen. Also, padding just means padding, not zero or sign extending. Yep, the standard does not mandate how it is to be implemented, but it DOES mandate that a literal 0 can be used as a null pointer, which requires that printf(%p, 0 ) work properly. That effectively requires the implementation to zero extend all arguments out to the same size. Either way, NULL is certainly supposed to work there according to the standard, so you shouldn't need (char *)0. For that matter, why would you printf NULL directly anyhow? Usually you would be printing a pointer variable, which you may have assigned to NULL, making this va args discussion moot. Nothing says that they should be extended, and I don't see why a compiler would go and fill data in something it shouldn't. On the other hand the standard does say that a char and a short should be prompted to an integer. See above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Kurt Roeckx wrote: You pass something different to printf(). In the first case you pass an integer, in the second case you pass a pointer. If sizeof(int) != sizeof(void *) you clearly have a problem. The promotion rules does not change it from interger to a longer type. So if you want to pass a NULL pointer you need to explicitly cast it. With va args, the arguments are always passed in a uniform size ( with padding as needed ), which is MAX( sizeof( void * ), sizeof( long ) ), so it doesn't make any difference. Try this on for instance amd64: printf(%p %p %p %p %p %p %p %p\n, 1, (void *)2, 3, 4, 5, 6, 7, 8); The result is: 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x7fff0008 Seems to accept 1 and (void *)2 as pointers just fine. What is with the 8 getting screwed up though? Or: printf(%p %p %p %p %p %p %p %p %p %p\n, 1, (void *)2, 3, 4, 5, 6, 7, 8, 9, 10); gives: 0x1 0x2 0x3 0x4 0x5 0x6 0x2b6c0007 0x8 0x9 0x7fff000a and: printf(%p %p %p %p %p %p %p %p %p %p\n, 1, (void *)2, 3, 4, 5, 6, 7, 8, 9, (void *)10); 0x1 0x2 0x3 0x4 0x5 0x6 0x2ba90007 0x8 0x9 0xa Looks like a bug in the compiler to me. It appears to be padding out the integers to 64 bits like it should, but not zeroing the padding bits, instead leaving them as undefined values. The reason this works for a few without paramters has to do with calling convention and implementation details. With other words, it's pure luck. Just like it's pure luck that casting the 10th parameter to a void * gets you the right value again, because amd64 does stdarg different than most arches in Debian. You could also argue that since it's passed as an interger instead of a pointer it might actually pass the wrong value, even in case sizeof(int) == sizeof(void *). A NULL pointer does not need to be represented as all bits 0, but you can still write it as 0. Anyway, for those who care, I prefer to write it as (void *)NULL. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Ian Jackson wrote: I can see that that would be helpful but in practice doing things that way makes the coding a lot harder. Normally, for a smallish change, I would definitely try to make separate patches for anything else I stumbled across. Likewise if I thought there was a serious possibility that some of my changes would need to remain as a separate branch for a long time while others are merged into the trunk. How is it a lot harder to keep things simple? For instance, if you add a new locking mechanism, then modify the existing code to use the new system, the new locking mechanism should not disturb existing code since it is new, so it can easily be committed as it's own logical change. Then commit the modification of the existing code to use the new locking mechanism separately, and now the locking mechanism and its use can be reviewed easier in their own right. One person might review the locking mechanism commit but know nothing about the existing code you later change to use it. That may lead to him deciding to convert some other code to use it, or suggest some changes to it. It makes his life easier when he doesn't have to sort through a larger patch that also contains a bunch of code he doesn't have any familiarity with. But when one's doing the kind of substantial engineering required in this case, the extra mindspace needed to retain the different branches, merge the bugfixes in the right way, and so forth, is often better spent on remembering how all of the code and semantics fitted together. Reviewing the changes is MUCH easier in bite sized chunks, and going through the trouble of figuring out which parts are logically independent and can be cut as separate commits ends up helping you to better understand what you are doing as well. In 6 months when you come back to the code and forgot it all, reviewing the shortlog for 30 seconds is more likely to refresh a lot more of your memory with smaller commits too. Then you have debugging... while trying to narrow down which change introduced a bug, having small commits allows git-bisect to help you quickly figure out EXACTLY which change caused the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Mon, Oct 29, 2007 at 05:09:55PM -0400, Phillip Susi wrote: Kurt Roeckx wrote: I think you're talking about an implementations of stdargs here, not what the standards says should happen. Also, padding just means padding, not zero or sign extending. Yep, the standard does not mandate how it is to be implemented, but it DOES mandate that a literal 0 can be used as a null pointer, After it has been promoted to a pointer. which requires that printf(%p, 0 ) work properly. Which does not prompote it to a pointer. That effectively requires the implementation to zero extend all arguments out to the same size. Either way, NULL is certainly supposed to work there according to the standard, so you shouldn't need (char *)0. For that matter, why would you printf NULL directly anyhow? Usually you would be printing a pointer variable, which you may have assigned to NULL, making this va args discussion moot. The code in question was doing an execlp() call. You should end the list of arguments with a NULL pointer. I was just using printf() here to show the problem since it also uses stdargs. The manpage explicity says that it should be casted. All the examples SUS show that it's casted. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Ian, I really don't understand why you On Thu, 25 Oct 2007, Ian Jackson wrote: I made a deliberate choice to publish my triggers work as a branch that could be merged in both directions. 1/ Only the official branch might be merged repeatedly in your branch. 2/ Your branch will be merged only once on the official branch (further bugfixes after the merge will be directly done on the officiel branch since you have commit rights there). That was necessary to facilitate merging changes from Debian into the Stop contesting everything please. It was not necessary. Please understand that rebasing one branch over the other also produces a result where the changes are merged (but the history is presented in a different way). revised. It meant I could merge fixes from the trunk into the triggers branch, and then into the flex branch, or just into the flex And you could just as well rebase your flex branch on top of the triggers branch. undue difficulty. (By undue difficulty I mean without imposing undue work on a human, for example by generating spurious conflicts on merging or requiring a particular conflict to be resolved twice.) It If you had followed my advice from the beginning, you'd not have had to resolve the conflict twice. meant that I could publish triggers, and my flex experiment, in a way that means that other people can edit their own versions and contribute aappropriate. We already had this discussion on IRC, it's very annoying to have it again. 1/ You're most likely the only person working on top of those branches (the copies in the nature are just read-only). 2/ You can leave the published repository as is and create another repository containing a rebased branch specifically for upstream submission. That was the suggestion made by Colin and which looked sensible. I was able to do all of these things straightforwardly and with a minimum of fuss, once I'd got used to git's slightly odd terminology and the usual initial kind of minor stumbling block with a new tool. The only problem seems to me that you are objecting to this mode of interaction. Can you please explain what is lost by my approach ? I'm not objecting to it in general. It's a very valid approach but since you want the dpkg team to merge that branch in the main branch, I expect that branch to be following the guidelines for the commit logs and to have valid emails. I suggested you to have those fixed. But this is not doable without rewriting the history (using git-rebase and git-filter-branch). Next time when you have everything straight from the beginning, it will be ok to work this way. On the other hand, I really have the impression that you have an unexplained fear of git-rebase and that you refuse it without even trying to understand what it does. If this is a deliberate choice, then why not. But I believe this is just the result of not having set up the user.name and user.email git configuration items... No, it's due to a bug in the Debian git package, which should have acquired my email address in the standard way. In that case it would have used a correct address. Honestly I don't care whose fault it is. Feel free to submit a wishlist bug against git. Most git tutorials start by explaining that you need to configure this. Well, plain git rebase compared to git merge only avoids (possibly repeated) merge commits. It doesn't change contents of the patches and doesn't changes author dates / emails. AIUI git rebase also prevents repeated merging backwards and forwards between different branches. Yes. But you can just as well use rebase between those branches! Many git tools rely on this convention to offer differing short/long view of changesets. So I don't like when the first line of the commit log is: dpkg (1.14.5ubuntu16) gutsy; urgency=low I agree that this is unhelpful. I can't remember why I didn't use debcommit at that point but I'm using it nowadays and I'm happy to continue doing so. Is there really merit in going back and fixing old commit log entries ? I have no ultimate answer. What I know is that if I were you, I'd do it. Then you're right, it looses history, so it's not required to proceed that way. But in many cases, it can ease the review because you'll present your change as a coherent serie of patches: - logical change 1 - logical change 2 - logical change 3 The actual triggers functionality isn't sensibly divisible in this way and the individual bugfixes which I've made at the same time are too trivial to care about in this way. Well, as someone who is not familiar with dpkg's C codebase, I really disagree. Small commits are easier to understand because you see all the related changes. Here are some examples of changes that I would have liked to see in seperate commits: - Move some functions into libdpkg - Created locksomething and modified lockdatabase to use that generic lock function (needed to be able to
Re: Triggers status?
On Wed, 24 Oct 2007, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): Well, either you merge or you use rebase. Using both doesn't make much sense! This branch has already been merged from the trunk once previously, after I published it for the first time. There were conflicts to fix up then too. So as I understand it that would mean that it's too late to rebase ? 1/ Using gitk, I don't find any trace of that previous merge. 2/ It's never too late, it's just a bit less handy, cf what I said in the previous mail. I think the rebase workflow doesn't really work for something as substantial as this which has to be published and examined by others while development continues on the trunk. I don't see why it wouldn't work. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Ian Jackson: This isn't a matter of preference, I'm afraid. I reverted this because the change was wrong. NULL is incorrect in that context (a stdarg function expecting a char*), because it may be #define'd to 0. NULL will always do, no matter if it is defined to 0 or (void *) 0. Try this: char *p = 1; // produces compiler warning char *p = 0; // does not -- \\// Peter - http://www.softwolves.pp.se/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog writes (Re: Triggers status?): CONFLICT (content): Merge conflict in lib/Makefile.am CONFLICT (content): Merge conflict in lib/dbmodify.c CONFLICT (content): Merge conflict in lib/dpkg.h CONFLICT (content): Merge conflict in lib/ehandle.c CONFLICT (delete/modify): lib/fields.c deleted in HEAD and modified in debian-patch. Version debian-patch of lib/fields.c left in tree. CONFLICT (content): Merge conflict in lib/parse.c CONFLICT (content): Merge conflict in lib/tarfn.c CONFLICT (add/add): Merge conflict in lib/trigdeferred.l CONFLICT (add/add): Merge conflict in lib/triglib.c CONFLICT (content): Merge conflict in src/Makefile.am CONFLICT (content): Merge conflict in src/configure.c CONFLICT (add/add): Merge conflict in src/trigproc.c Automatic merge failed; fix conflicts and then commit the result. This is precisely what using a merge tracking drcs, used properly, is supposed to avoid. And it is exactly what my approach _does_ avoid. If you just merge my patch into your head, I'll be able to pull from your head into my flex branch without any spurious conflicts. I just tried it and there's just one conflict in lib/parse.c which I is an actual real conflict between some changes I made on the triggers branch after my last merge into the flex branch. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Thu, 25 Oct 2007, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): Automatic merge failed; fix conflicts and then commit the result. This is precisely what using a merge tracking drcs, used properly, is supposed to avoid. And it is exactly what my approach _does_ avoid. I know this, I don't need to learn it. :-) And it would be wise fine to proceed that way if your history was clean and all. I was just showing you that loosing the history doesn't involve as much work as you expected to, but of course it's more work. You can't get everything: - either you fix the history and you get some more conflicts to handle (but not as many as you expected) - or you keep the problematic history and provided that this history is merged by the dpkg maintainers, you'll have less conflicts to handle But as I said, if I were an official dpkg maintainer, I wouldn't merge history that looks like this in gitweb: 33325ac Merge ../dpkg.base 13c3738 Reapply Remove duplicate nested conditional etc. 2791b4c Revert Fix failed remove resulting in installed state 5565fa4 Revert to untangle ``Remove duplicate nested conditional ...'' [...] da517d0 dpkg (1.14.5ubuntu16) gutsy; urgency=low 5f25773 dpkg (1.14.5ubuntu15) gutsy; urgency=low 1620746 dpkg (1.14.5ubuntu14) gutsy; urgency=low 9ed9425 + dpkg (1.14.5ubuntu13) gutsy; urgency=low 45b5781 remove unused variable f_verbose ee4bd47 add %nounput to trigdeferred.l 502affd + dpkg (1.14.5ubuntu10) gutsy; urgency=low fb7f439 + dpkg (1.14.5ubuntu9~~) unstable; urgency=low 1ab6796 triggers initial implementation as of 1.14.5ubuntu8 8c02ed9 triggers initial implementation as of 1.14.5ubuntu8 So I would rather generate the diff associated to that, and apply the diff with a proper commit message. You have the opinion of someone else who managed to put patches in dpkg. HTH and you're free to wait the input of Guillem on this topic. Cheers, PS: If you want to compare, here's what looks like my last merge: 036c800 ChangeLog: move everything related to Dpkg::Deps at the same date. 6b50675 Dpkg::Deps: add some integrated POD documentation of the API 065910a Update dpkg-gencontrol's man page to mention its handling of dependency fields 79157e8 Update changelog entries concerning the integration of Dpkg::Deps. 8cf298f controllib.pl: Remove obsolete and unused functions and variables. 7811be9 dpkg-scanpackages: Use @pkg_dep_fields from Dpkg::Deps cd7b1b2 dpkg-checkbuilddeps: modify to use the new Dpkg::Deps module 6cda719 dpkg-source: use the new Dpkg::Deps module instead of controllib's parsedep f143c9d dpkg-gencontrol: use the new Dpkg::Deps module to rewrite the dependencies 847f78a Include the new scripts/Dpkg/Deps.pm in the dpkg-dev package 6aef17c Add new module Dpkg::Deps to handle dependencies and some corresponding tests And yes I invested time to obtain this result by squashing bug fixes into previous commits and by making the effort to commit individual logical change. -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog writes (Re: Triggers status?): And it would be wise fine to proceed that way if your history was clean and all. I was just showing you that loosing the history doesn't involve as much work as you expected to, but of course it's more work. I don't know what you mean by `not as much as you expected'. The results you demonstrated seemed entirely consistent with what I expected and it is precisely that kind of merging makework that my approach avoids. Doing extra merge work for the benefit of cosmetic redaction of commit logs (which is IMO itself of doubtful value) seems an absurd tradeoff. Merging substantial conflicting changes is one of the most demanding and error-prone programming tasks. I'm astonished that you're seriously advocating a workflow that prefers to have humans running around fixing up mistakes made by computers. However I think that this conversation between you and me isn't going anywhere useful. We're going round in circles. Would anyone else like to comment ? Guillem, do you have an opinion about the use of git or (preferably!) about the actual code ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Thu, Oct 25, 2007 at 09:09:23AM +0100, Peter Karlsson wrote: Ian Jackson: This isn't a matter of preference, I'm afraid. I reverted this because the change was wrong. NULL is incorrect in that context (a stdarg function expecting a char*), because it may be #define'd to 0. NULL will always do, no matter if it is defined to 0 or (void *) 0. Try this: char *p = 1; // produces compiler warning char *p = 0; // does not The problem is with stdarg calls, like Ian said. If you do printf(%p, 0); or printf(%p, (void *)0); You pass something different to printf(). In the first case you pass an integer, in the second case you pass a pointer. If sizeof(int) != sizeof(void *) you clearly have a problem. The promotion rules does not change it from interger to a longer type. So if you want to pass a NULL pointer you need to explicitly cast it. Try this on for instance amd64: printf(%p %p %p %p %p %p %p %p\n, 1, (void *)2, 3, 4, 5, 6, 7, 8); The result is: 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x7fff0008 Or: printf(%p %p %p %p %p %p %p %p %p %p\n, 1, (void *)2, 3, 4, 5, 6, 7, 8, 9, 10); gives: 0x1 0x2 0x3 0x4 0x5 0x6 0x2b6c0007 0x8 0x9 0x7fff000a and: printf(%p %p %p %p %p %p %p %p %p %p\n, 1, (void *)2, 3, 4, 5, 6, 7, 8, 9, (void *)10); 0x1 0x2 0x3 0x4 0x5 0x6 0x2ba90007 0x8 0x9 0xa The reason this works for a few without paramters has to do with calling convention and implementation details. With other words, it's pure luck. Just like it's pure luck that casting the 10th parameter to a void * gets you the right value again, because amd64 does stdarg different than most arches in Debian. You could also argue that since it's passed as an interger instead of a pointer it might actually pass the wrong value, even in case sizeof(int) == sizeof(void *). A NULL pointer does not need to be represented as all bits 0, but you can still write it as 0. Anyway, for those who care, I prefer to write it as (void *)NULL. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Tue, 23 Oct 2007, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): You should have called git-update-server-info before the rsync! :-) Oh! Well, I've done that now. Hopefully that's better. I just gave a quick look to your branch: - please rebase it on the current master branch (that way you're sure that there are no conflicts) - please update your git identity, I see Ian Jackson [EMAIL PROTECTED]. You should standardize your contributions to a single email. FYI, your previous patches have been applied as Ian Jackson [EMAIL PROTECTED]. You can use git-filter-branch to rewrite that field automatically. - please update the commit logs, a copy/paste of the ubuntu changelog doesn't look good to me, follow the recommandation of using a summary in the first line, then an empty line, then a long description. see http://wiki.debian.org/Teams/Dpkg/GitUsage (this can be done during the interactive rebase process, see man git-rebase and its -i option) - you can also restructure the serie of changes with git rebase -i origin/master (provided that origin/master is an up-to-date copy of the master branch of the main dpkg repository) (merge several commits in a single, in particular bug fixes with initial implementation so that while reviewing diff you don't find bugs which are in fact fixed by a subsequent commit) I did this for my deps-rewrite branch, the serie of patchs always stayed the same: 1/ Adding Dpkg::Deps and its testsuite 2/ Modify dpkg-gencontrol 3/ Modify dpkg-checkbuildeps ... Each time I had a bugfix, I squashed the bugfix commit into the corresponding logical commit (using git rebase -i origin/master). I can't judge the content but following the right form is more likely to lead to a quicker review. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog [EMAIL PROTECTED] writes: Each time I had a bugfix, I squashed the bugfix commit into the corresponding logical commit (using git rebase -i origin/master). If the bugfix is unrelated, is nice to put it in a separate branch for merging too so it's easier to have a global view of real changes need and not a mix of them. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog wrote: I just gave a quick look to your branch: I can understand why all these might be best practices for submitting patches via git for a project like the linux kernel, but dpkg is not exactly drowning in perfectly-presented git patchsets, and IMHO there are good reasons to ignore every suggestion you made. - please rebase it on the current master branch (that way you're sure that there are no conflicts) I have yet to see a use of git rebase that I am comfortable with. History is very important to me, even the ugly bits. Being able to see every misttep that was committed actually helps understanding the end result. Merging it with the current upstream master would have the same effect with a more ugly history, surely? - please update your git identity, I see Ian Jackson [EMAIL PROTECTED]. You should standardize your contributions to a single email. FYI, your previous patches have been applied as Ian Jackson [EMAIL PROTECTED]. You can use git-filter-branch to rewrite that field automatically. Again, history is important to me, in this case I quite like that git preserves a history of where I did my work, so I have no interest in using a single email address. (AFAIK, this isn't even a general best practice. For example Linus commits from [EMAIL PROTECTED] and signs off patches from [EMAIL PROTECTED] Earlier in the kernel history, it's [EMAIL PROTECTED]) - please update the commit logs, a copy/paste of the ubuntu changelog doesn't look good to me, follow the recommandation of using a summary in the first line, then an empty line, then a long description. see http://wiki.debian.org/Teams/Dpkg/GitUsage (this can be done during the interactive rebase process, see man git-rebase and its -i option) Again, history is important to me, moreover, this is a lot of work for essentially zero gain. Yes, I'm lazy. If I have a perfectly ok changelog entry in debian/changelog, I will debcommit it, and not reiterate the same changes in a different style. - you can also restructure the serie of changes with git rebase -i origin/master (provided that origin/master is an up-to-date copy of the master branch of the main dpkg repository) (merge several commits in a single, in particular bug fixes with initial implementation so that while reviewing diff you don't find bugs which are in fact fixed by a subsequent commit) This loses history, is highly complex, requires a significant knowledge of git (more than I am comfortable with after using it for a month), and AFAICS is an anourmous time sink for no benefit. I'd rather be coding. I can't judge the content but following the right form is more likely to lead to a quicker review. If that's actually true of dpkg, I'll be sure to limit the information I publish about dpkg patches to unified diffs and avoid all this nonsense. As someone who needs this patch merged as soon as possible so we can start *using* it, your comments came off as somewhat tinged with obstructionism and git fanboyism. I'm sure you didn't intend that, but that was my impression. :-/ -- see shy jo signature.asc Description: Digital signature
Re: Triggers status?
On Wed, 24 Oct 2007, Joey Hess wrote: I can understand why all these might be best practices for submitting patches via git for a project like the linux kernel, but dpkg is not exactly drowning in perfectly-presented git patchsets, and IMHO there are good reasons to ignore every suggestion you made. When there are good reasons, I'm happy to let anyone ignore my suggestions. But in this case, given that Ian is just learning git usage I believe that most of the things listed are consequences of errors / lack of knowledge rather than deliberate choices. - please rebase it on the current master branch (that way you're sure that there are no conflicts) I have yet to see a use of git rebase that I am comfortable with. History is very important to me, even the ugly bits. Being able to see every misttep that was committed actually helps understanding the end result. Merging it with the current upstream master would have the same effect with a more ugly history, surely? Well, plain git rebase compared to git merge only avoids (possibly repeated) merge commits. It doesn't change contents of the patches and doesn't changes author dates / emails. I fail to see what (important) history is lost. - please update your git identity, I see Ian Jackson [EMAIL PROTECTED]. You should standardize your contributions to a single email. FYI, your previous patches have been applied as Ian Jackson [EMAIL PROTECTED]. You can use git-filter-branch to rewrite that field automatically. Again, history is important to me, in this case I quite like that git preserves a history of where I did my work, so I have no interest in using a single email address. (AFAIK, this isn't even a general best practice. For example Linus commits from [EMAIL PROTECTED] and signs off patches from [EMAIL PROTECTED] Earlier in the kernel history, it's [EMAIL PROTECTED]) If this is a deliberate choice, then why not. But I believe this is just the result of not having set up the user.name and user.email git configuration items... - please update the commit logs, a copy/paste of the ubuntu changelog doesn't look good to me, follow the recommandation of using a summary in the first line, then an empty line, then a long description. see http://wiki.debian.org/Teams/Dpkg/GitUsage (this can be done during the interactive rebase process, see man git-rebase and its -i option) Again, history is important to me, moreover, this is a lot of work for essentially zero gain. Yes, I'm lazy. If I have a perfectly ok changelog entry in debian/changelog, I will debcommit it, and not reiterate the same changes in a different style. Many git tools rely on this convention to offer differing short/long view of changesets. So I don't like when the first line of the commit log is: dpkg (1.14.5ubuntu16) gutsy; urgency=low At least debcommit provides real a changelog entry on the first line... even if it's not a summary line, it's way better than this (in particular when your respect the a commit == a change rule). - you can also restructure the serie of changes with git rebase -i origin/master (provided that origin/master is an up-to-date copy of the master branch of the main dpkg repository) (merge several commits in a single, in particular bug fixes with initial implementation so that while reviewing diff you don't find bugs which are in fact fixed by a subsequent commit) This loses history, is highly complex, requires a significant knowledge of git (more than I am comfortable with after using it for a month), and AFAICS is an anourmous time sink for no benefit. I'd rather be coding. Honestly I wouldn't suggest it if it wasn't dead easy. I takes a few seconds at most to squash a changeset in another one. Then you're right, it looses history, so it's not required to proceed that way. But in many cases, it can ease the review because you'll present your change as a coherent serie of patches: - logical change 1 - logical change 2 - logical change 3 - ... Instead of: - logical change 1 - logical change 2 - bug fix on logical change 1 - bug fix on ... - ... - logical change 3 - ... I can't judge the content but following the right form is more likely to lead to a quicker review. If that's actually true of dpkg, I'll be sure to limit the information I publish about dpkg patches to unified diffs and avoid all this nonsense. Sure, patches are perfectly fine. As someone who needs this patch merged as soon as possible so we can start *using* it, your comments came off as somewhat tinged with obstructionism and git fanboyism. I'm sure you didn't intend that, but that was my impression. :-/ I certainly didn't intend that and if you have followed, I pushed Guillem and Frank hard to get my own work merged. So I only share my experience. I wish we could have a quicker review/integration cycle. But submitting a git branch in the form that Ian used doesn't
Re: Triggers status?
Ian Jackson writes (Re: Triggers status?): If I rebase this branch, will this cause trouble for my flex-based parser branch, which I took off from the triggers code ? Following somewhat inconclusive discussion on IRC about these and related questions, I said I would go away and try this. Firstly, I had to merge my triggers branch with the latest head. I've done this now and the result is in the same place as before: http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/ While doing the merge I found that the triggers patch conflicted with the change to the semantics of successful postinst completion, which was made pursuant to bug #443334. As readers may know, I disagree with that change. In any case, as the triggers branch consolidates some of the cleanup postinst functionality in a single place, it will be more expedient to revert the patch from #444 first and redo it again if it is still felt to be correct. So for now I have reverted that change in my triggers branch. Obviously I think it should be merged as-is. I then tried to use rebase, like this: cp -a dpkg.triggers dpkg.triggers.rebase cd dpkg.triggers.rebase/ git-fetch ../dpkg.debian master:debian-head # where ../dpkg.debian is a straightforward pull of the head git-rebase debian-head This produced a great deal of output including complaints, for example: error: patch failed: debian/control:6 error: debian/control: patch does not apply and: CONFLICT (content): Merge conflict in src/cleanup.c Just to check that it's not anything wrong with my triggers branch I did this too: cp -a dpkg.debian dpkg.debian.merge cd dpkg.debian.merge/ git pull ../dpkg.triggers which seemed to work perfectly. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Wed, 24 Oct 2007, Ian Jackson wrote: I then tried to use rebase, like this: cp -a dpkg.triggers dpkg.triggers.rebase cd dpkg.triggers.rebase/ git-fetch ../dpkg.debian master:debian-head # where ../dpkg.debian is a straightforward pull of the head git-rebase debian-head This produced a great deal of output including complaints, for example: error: patch failed: debian/control:6 error: debian/control: patch does not apply and: CONFLICT (content): Merge conflict in src/cleanup.c This is just the normal behaviour since you have a conflict in the rebase. You just have to fix it exactly like you fixed the conflict when you did the merge. If you look at the output more carefully, you first see: error: patch failed: debian/control:6 error: debian/control: patch does not apply error: patch failed: src/cleanup.c:236 error: src/cleanup.c: patch does not apply error: patch failed: src/remove.c:163 error: src/remove.c: patch does not apply This just tells you that the patches of the current changeset being rebased do not apply. Later on you see: Falling back to patching base and 3-way merge... Auto-merged configure.ac Auto-merged debian/control Auto-merged src/cleanup.c CONFLICT (content): Merge conflict in src/cleanup.c Auto-merged src/remove.c Failed to merge in the changes. It means that most of the changes have been merged properly except the part that concerns src/cleanup.c. You can do a git diff and you'll see the conflict: $ git diff diff --cc src/cleanup.c index d1ebb68,29ac8fe..000 --- a/src/cleanup.c +++ b/src/cleanup.c @@@ -237,9 -229,8 +230,13 @@@ void cu_prermremove(int argc, void **ar if (cleanup_pkg_failed++) return; maintainer_script_installed(pkg,POSTINSTFILE,post-installation, ++ HEAD:src/cleanup.c + abort-remove, NULL); + pkg-status= *oldpkgstatus; ++=== + abort-remove, (char*)0); ++ triggers initial implementation as of 1.14.5ubuntu8:src/cleanup.c pkg-eflag = ~eflagf_reinstreq; - modstatdb_note(pkg); + cu_postinstdone(pkg); cleanup_pkg_failed--; } At that point, you manually fix the conflict with your editor and you do git add src/cleanup.c to indicate that your resolved the conflict. Then you continue the rebase process with git rebase --continue. You might have to do that multiple times if there are more conflicts. But in any case those conflicts would also arise with a git merge so it's not git-rebase's fault. Just to check that it's not anything wrong with my triggers branch I did this too: cp -a dpkg.debian dpkg.debian.merge cd dpkg.debian.merge/ git pull ../dpkg.triggers which seemed to work perfectly. Unless you had dpkg.debian already merged in your dpkg.triggers branch, I don't understand this. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
* Ian Jackson [Wed, 24 Oct 2007 18:41:31 +0100]: cp -a dpkg.triggers dpkg.triggers.rebase If I'm not mistaken, you can store all your branches in a single directory/git repository, unlike in other VCSes (like Bazaar). HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - No more band? - No more band. - You are not the daughter I raised! - What? - Kims don't give up! -- Mrs. Kim and Lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog writes (Re: Triggers status?): This is just the normal behaviour since you have a conflict in the rebase. You just have to fix it exactly like you fixed the conflict when you did the merge. But I already fixed up that conflict when I merged the head into dpkg.triggers. Why do I need to do it again ? Surely the point of using an advanced revision control system is to avoid this kind of makework. Sorry to be tetchy but I guess I'm missing the way in which this is making our lives easier rather than harder. Unless you had dpkg.debian already merged in your dpkg.triggers branch, I don't understand this. Yes, that's exactly what I have. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Wed, 24 Oct 2007, Ian Jackson wrote:
Firstly, I had to merge my triggers branch with the latest head. I've
done this now and the result is in the same place as before:
http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/
Some more random remarks, this time on the content of the patches.
* you replaced a bunch of NULL by (char*)0. This reverts
http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e
I believe you should use NULL everywhere. (My personal taste also favors
NULL over (char*)0 but it's not even a question of what I prefer since
I'm not an official dpkg maintainer)
* it would have been nice to have the various bits of refactoring somewhat
separated (in other commits I mean) to simplify the review (it's still
doable with git rebase -i, selecting edit on commits to split, and
then using git add -i to add subset of changes to the index and to
commit them in several steps).
I say this for the future but it's not a pre-requesite for further
review (at least not on my part).
Direct patch review:
@@ -109,6 +109,7 @@ static void usage(void) {
-E|--skip-same-version Skip packages whose same version is installed.\n
-G|--refuse-downgrade Skip packages with earlier version than
installed.\n
-B|--auto-deconfigure Install even if it would break some other
package.\n
+ [--no-]triggersSkip or force consequential trigger
processing.\n
--no-debsigDo not try to verify package signatures.\n
--no-act|--dry-run|--simulate\n
Should logically be --[no-]triggers.
No remarks on the core of the patch, as I'm not familiar enough with the
C codebase.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Wed, 24 Oct 2007, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): This is just the normal behaviour since you have a conflict in the rebase. You just have to fix it exactly like you fixed the conflict when you did the merge. But I already fixed up that conflict when I merged the head into dpkg.triggers. Why do I need to do it again ? Surely the point of using an advanced revision control system is to avoid this kind of makework. Well, either you merge or you use rebase. Using both doesn't make much sense! The point was to do the rebase when your branch was still pointing to your commit da517d03a69942016d3e90fd6fbbf462645109e4. The situation was this one: o--o--o--o dpkg.debian \ o--o--o dpkg.triggers You did this: o--o--o--o dpkg.debian \\ o--o--o--o dpkg.triggers Using rebase would have lead to this: o--o--o--o dpkg.debian \ o--o--o dpkg.triggers In fact, you can still do the rebase after the merge but it will simply try to apply all the patches that are in dpkg.triggers on top of dpkg.debian including the merge patch. Which means you'll see the conflicts live (when the conflicting patch is replayed on top of dpkg.debian) and you'll see it again when the merge patch is going to be replayed. So really it's not very interesting to merge first if you intend to rebase after. (your real example is even more complicated as you didn't fix the conflict in the merge commit but reverted changes that lead to conflicts on top of the dpkg.debian tree before merging that into your dpkg.triggers tree, urgh!) Sorry to be tetchy but I guess I'm missing the way in which this is making our lives easier rather than harder. Using rebase is no more complicated than using merge for you. It just generates a different result. I already explained in what way rebase is interesting (rewriting the history to make it easier to review and to match the commit guidelines of the team that should merge the branch). Unless you had dpkg.debian already merged in your dpkg.triggers branch, I don't understand this. Yes, that's exactly what I have. So it was logical: The merge simply changed this: o--o--o--o dpkg.debian \\ o--o--o--o dpkg.triggers Into this: o--o--o--o \\ o--o--o--o dpkg.triggers, dpkg.debian All dpkg.debian commits were already in dpkg.triggers so the merge had nothing to do except make the dpkg.debian branch point to dpkg.triggers. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog writes (Re: Triggers status?): * you replaced a bunch of NULL by (char*)0. This reverts http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e I believe you should use NULL everywhere. (My personal taste also favors NULL over (char*)0 but it's not even a question of what I prefer since I'm not an official dpkg maintainer) This isn't a matter of preference, I'm afraid. I reverted this because the change was wrong. NULL is incorrect in that context (a stdarg function expecting a char*), because it may be #define'd to 0. I had to make a decision about it since the (char*)0 - NULL change was made after I started my branch, so at some point when I merged it resulted in an edit conflict. * it would have been nice to have the various bits of refactoring somewhat separated (in other commits I mean) to simplify the review (it's still doable with git rebase -i, selecting edit on commits to split, and then using git add -i to add subset of changes to the index and to commit them in several steps). I say this for the future but it's not a pre-requesite for further review (at least not on my part). I can see that that would be helpful but in practice doing things that way makes the coding a lot harder. Normally, for a smallish change, I would definitely try to make separate patches for anything else I stumbled across. Likewise if I thought there was a serious possibility that some of my changes would need to remain as a separate branch for a long time while others are merged into the trunk. But when one's doing the kind of substantial engineering required in this case, the extra mindspace needed to retain the different branches, merge the bugfixes in the right way, and so forth, is often better spent on remembering how all of the code and semantics fitted together. Direct patch review: ... + [--no-]triggersSkip or force consequential trigger processing.\n Should logically be --[no-]triggers. Well spotted; fixed. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog writes (Re: Triggers status?): Well, either you merge or you use rebase. Using both doesn't make much sense! This branch has already been merged from the trunk once previously, after I published it for the first time. There were conflicts to fix up then too. So as I understand it that would mean that it's too late to rebase ? I think the rebase workflow doesn't really work for something as substantial as this which has to be published and examined by others while development continues on the trunk. In fact, you can still do the rebase after the merge but it will simply try to apply all the patches that are in dpkg.triggers on top of dpkg.debian including the merge patch. Which means you'll see the conflicts live (when the conflicting patch is replayed on top of dpkg.debian) and you'll see it again when the merge patch is going to be replayed. So really it's not very interesting to merge first if you intend to rebase after. Right. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Ian Jackson writes (Re: Triggers status?): Raphael Hertzog writes (Re: Triggers status?): * you replaced a bunch of NULL by (char*)0. This reverts http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e ... This isn't a matter of preference, I'm afraid. I reverted this because the change was wrong. NULL is incorrect in that context (a stdarg function expecting a char*), because it may be #define'd to 0. I should be clearer about this. I looked at that change at the time and what it seemed to be was changing all instances of (char*)0 and (void*)0 and (struct something*)0 and the like into NULL. Unfortunately that is precisely wrong. My coding style (which is still mostly followed by most of the code) does not write (char*)0 where 0 would do - I like to write 0 for null pointers where possible. So in each case where I used (char*)0 I did so because NULL would have been wrong (barring of course the odd mistake on my part). Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Wed, Oct 24, 2007 at 01:27:22PM -0400, Joey Hess wrote: Raphael Hertzog wrote: I just gave a quick look to your branch: - please rebase it on the current master branch (that way you're sure that there are no conflicts) I have yet to see a use of git rebase that I am comfortable with. History is very important to me, even the ugly bits. Being able to see every misttep that was committed actually helps understanding the end result. Loosing the missteps like that is one of the explicit goals of doing this that Linus pushes for rebasing. The other thing with it (especailly with -i) is that it supports a workflow where patches are submitted using git-format-patch and git-send-email and reviews are iterated - this gives a patch per commit, allowing piecemeal review, but means that you need to edit history in order to do the iterations. Merging it with the current upstream master would have the same effect with a more ugly history, surely? Yes. As I understand it what's going on with the kernel is that it's aiming for a revision control history that looks a lot like things being submitted and reviewed as patches even where that's not technically what happens in all the stages the patch flows through. - you can also restructure the serie of changes with git rebase -i origin/master (provided that origin/master is an up-to-date copy of the master branch of the main dpkg repository) (merge several commits in a single, in particular bug fixes with initial implementation so that while reviewing diff you don't find bugs which are in fact fixed by a subsequent commit) This loses history, is highly complex, requires a significant knowledge of git (more than I am comfortable with after using it for a month), and AFAICS is an anourmous time sink for no benefit. I'd rather be coding. It can be useful if used with a workflow that it supports (I've used it with ones where individual commits get a fairly large amount of review) but I'm personally less sure about it when it's just the head of a branch that's getting reviewed. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Triggers status?
Raphael Hertzog writes (Re: Triggers status?): When there are good reasons, I'm happy to let anyone ignore my suggestions. But in this case, given that Ian is just learning git usage I believe that most of the things listed are consequences of errors / lack of knowledge rather than deliberate choices. I made a deliberate choice to publish my triggers work as a branch that could be merged in both directions. That was necessary to facilitate merging changes from Debian into the Ubuntu version. It enabled me to make my further substantial changes for my flex experiment based on code that wasn't going to be radically revised. It meant I could merge fixes from the trunk into the triggers branch, and then into the flex branch, or just into the flex branch if I wanted just to work on that at a particular time, without undue difficulty. (By undue difficulty I mean without imposing undue work on a human, for example by generating spurious conflicts on merging or requiring a particular conflict to be resolved twice.) It meant that I could publish triggers, and my flex experiment, in a way that means that other people can edit their own versions and contribute aappropriate. I was able to do all of these things straightforwardly and with a minimum of fuss, once I'd got used to git's slightly odd terminology and the usual initial kind of minor stumbling block with a new tool. The only problem seems to me that you are objecting to this mode of interaction. Can you please explain what is lost by my approach ? If this is a deliberate choice, then why not. But I believe this is just the result of not having set up the user.name and user.email git configuration items... No, it's due to a bug in the Debian git package, which should have acquired my email address in the standard way. In that case it would have used a correct address. Well, plain git rebase compared to git merge only avoids (possibly repeated) merge commits. It doesn't change contents of the patches and doesn't changes author dates / emails. AIUI git rebase also prevents repeated merging backwards and forwards between different branches. Many git tools rely on this convention to offer differing short/long view of changesets. So I don't like when the first line of the commit log is: dpkg (1.14.5ubuntu16) gutsy; urgency=low I agree that this is unhelpful. I can't remember why I didn't use debcommit at that point but I'm using it nowadays and I'm happy to continue doing so. Is there really merit in going back and fixing old commit log entries ? Then you're right, it looses history, so it's not required to proceed that way. But in many cases, it can ease the review because you'll present your change as a coherent serie of patches: - logical change 1 - logical change 2 - logical change 3 The actual triggers functionality isn't sensibly divisible in this way and the individual bugfixes which I've made at the same time are too trivial to care about in this way. Sure, patches are perfectly fine. If I were to supply patches and you were to apply them, my flex branch would be completely messed up, wouldn't it ? Next time I wanted to do a merge it would try to apply another copy of the triggers changes. The whole point of using a drcs is to avoid that kind of thing. I wish we could have a quicker review/integration cycle. But submitting a git branch in the form that Ian used doesn't help much unless you follow the conventions of the team. I don't understand how presenting it as a git branch can be inferior to presenting it as a patch. For the purposes of review, git can tell you exactly what the changes are. The difference is that if you merge from my branch, my other branches don't get trashed. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Anthony Towns writes (Re: Triggers status?): On Mon, Oct 22, 2007 at 05:43:45PM +0100, Ian Jackson wrote: * The dpkg triggers code should be merged from http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/ ] $ git clone http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers ] Initialized empty Git repository in /home/aj/H/dpkg/dpkg.triggers/.git/ ] Cannot get remote repository information. ] Perhaps git-update-server-info needs to be run there? git:// doesn't work either (Connection refused). What I did was rsync -a my local tree to my public-html directory on chiark. chiark is still running sarge so git isn't installed there. Is it not possible to provide a git branch in this way ? What should I have done instead ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Tue, 23 Oct 2007, Ian Jackson wrote: ] $ git clone http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers ] Initialized empty Git repository in /home/aj/H/dpkg/dpkg.triggers/.git/ ] Cannot get remote repository information. ] Perhaps git-update-server-info needs to be run there? git:// doesn't work either (Connection refused). What I did was rsync -a my local tree to my public-html directory on chiark. chiark is still running sarge so git isn't installed there. Is it not possible to provide a git branch in this way ? What should I have done instead ? You should have called git-update-server-info before the rsync! :-) But as Otavio explained, I would suggest you to use ~/public_git/ on Alioth like I did recently with my deps-rewrite branch. That way you get a gitweb for free. http://git.debian.org/?p=users/hertzog/dpkg.git git://git.debian.org/~hertzog/dpkg.git See http://wiki.debian.org/AliothGit for more infos. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog writes (Re: Triggers status?): You should have called git-update-server-info before the rsync! :-) Oh! Well, I've done that now. Hopefully that's better. But as Otavio explained, I would suggest you to use ~/public_git/ on Alioth like I did recently with my deps-rewrite branch. That way you get a gitweb for free. That sounds useful and I'll look into it. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Tue, Oct 23, 2007 at 03:58:00PM +0100, Ian Jackson wrote: Raphael Hertzog writes (Re: Triggers status?): You should have called git-update-server-info before the rsync! :-) Oh! Well, I've done that now. Hopefully that's better. \o/ git clone http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/.git/ now works. Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
Colin Watson writes (Triggers status?): I was wondering what the status of merging Ian's triggers work is; I can't find any comments by the dpkg maintainers on it. I've just been checking up on loose ends so for clarity here is my view of the situation. * The dpkg triggers code should be merged from http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/ #308285 is relevant but there is no specific bug report for this. The control file should declare Conflicts the current versions of apt and aptitude, because those programs need to be changed to cope with the new status values. This will keep the relevant version out of testing, and off people's machines, until apt and aptitude are upgrade. Note that the up-to-date specification of the triggers feature, which corresponds to the code, is included in the doc/ directory of that package. Guillem: in a spirit of trying to have better cooperation, can I ask that you if you feel you need to review these changes in detail you do so reasonably promptly, and get back to me with your * apt and aptitude need the patches applying for supporting the new status values: #438547 (apt) #438548 (aptitude). * There are also some cosmetic improvements to apt[itude] which it would be good to include, as otherwise the progress reporting bar doesn't accurately reflect the information (or lack of it) about trigger processing. I haven't dug these out and forwarded them to the Debian BTS as yet. Triggers can be deployed in Debian right away IMO without waiting for this change. In parallel, packages can already start making use of the new functionality. If this is done correctly it is possible to make a package which works properly. In Ubuntu such changes have been deployed successfully for ldconfig and update-initramfs. I've consilidated our changes into these two coherent patches: * #447609 (glibc): defer and consolidate executions of ldconfig * #447611 (initramfs-tools): ditto update-initramfs Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Oops, unfinished paragraph: Ian Jackson writes (Re: Triggers status?): Guillem: in a spirit of trying to have better cooperation, can I ask that you if you feel you need to review these changes in detail you do so reasonably promptly, and get back to me with your comments. I promise to try to engage constructively with the substance of any criticisms you have and to make any changes that we agree. If we cannot agree I suggest that we seek consensus here on this list. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Sun, Oct 21, 2007 at 11:30:08PM -0500, Manoj Srivastava wrote: On Mon, 22 Oct 2007 07:01:33 +1000, Anthony Towns wrote: This is because the default is to deny by default -- and thus security policy modules _add_ the permissions for special tasks that packages need to do. Lacking security policy does not mean you have a security hole -- Oh, well in that case you only need it to happen before the postinst, not before the preinst. That's much closer to something triggers could do -- for instance, if you hacked libc6 to be interested in a file trigger for /, then anytime you installed an arch:any package, you'd have: libc6 installed, foo-any uninstalled foo-any unpack libc6 trigger-await, foo-any unpacked libc6.postinst triggered / libc6 installed, foo-any unpacked foo-any.postinst configure libc6 installed, foo-any installed The foo-any Depends: libc6 relationship is required for that ordering to be guaranteed, afaics though. Generalising that to some sort of Ensure-Always-Configured: yes header that the selinux-policy package could use might be feasible though. (All of the above assumes my understanding of triggers is accurate; I haven't looked at the code) Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Mon, Oct 22, 2007 at 05:43:45PM +0100, Ian Jackson wrote: * The dpkg triggers code should be merged from http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/ ] $ git clone http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers ] Initialized empty Git repository in /home/aj/H/dpkg/dpkg.triggers/.git/ ] Cannot get remote repository information. ] Perhaps git-update-server-info needs to be run there? git:// doesn't work either (Connection refused). Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Mon, 22 Oct 2007 23:15:13 +1000, Anthony Towns [EMAIL PROTECTED] said: On Sun, Oct 21, 2007 at 11:30:08PM -0500, Manoj Srivastava wrote: On Mon, 22 Oct 2007 07:01:33 +1000, Anthony Towns wrote: This is because the default is to deny by default -- and thus security policy modules _add_ the permissions for special tasks that packages need to do. Lacking security policy does not mean you have a security hole -- Oh, well in that case you only need it to happen before the postinst, not before the preinst. That's much closer to something triggers could do -- for instance, if you hacked libc6 to be interested in a file trigger for /, then anytime you installed an arch:any package, you'd have: Unfortunately, that would mean a different hack for dpkg, or a relabel; current dpkg has been patched to correctly set the file label as things are unpacked. So, if the proper file contexts are not in place before the unpack happens, installing the policy _after_ the fat is not enough -- we need to correct the permissions, which is messier. Also, while I am reasonably convinced the short period of time between unpack and postinst with the wrong permissions does not open security holes, this is based on an offhand analysis of the security policy; not on any formal information flow analysis, so I would much prefer _not_ to have this window with wrong security labels to exist in the first place. So, once I have some time, I'll be looking into doing an early hook, rather than trying to coerce triggers to do the task. Interesting suggestion, though. manoj -- It gets late early out there. Yogi Berra Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Fri, Oct 19, 2007 at 08:56:57AM +, Colin Watson wrote: I would understand the delay if there were some major problem that had been identified - but it all seems to work and it's a substantial advance that would let me simplify a bunch of stuff, so please forgive my impatience. :-) Is there a quick intro to using the triggers implementation anywhere around (this list's archives, maybe)? Or would you care to give a quick intro? Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Sun, Oct 21, 2007 at 10:04:34PM +1000, Anthony Towns wrote:
On Fri, Oct 19, 2007 at 08:56:57AM +, Colin Watson wrote:
I would understand the delay if there were some major problem that
had been identified - but it all seems to work and it's a
substantial advance that would let me simplify a bunch of stuff, so
please forgive my impatience. :-)
Is there a quick intro to using the triggers implementation anywhere
around (this list's archives, maybe)? Or would you care to give a
quick intro?
Ian's final design is here and has a worked example:
http://lists.debian.org/debian-dpkg/2007/04/msg00076.html
I've attached my patch for man-db to make it use triggers, minus the
changes to debian/po/*. Basically, I install a 'triggers' control file
registering interest in all the manual page directory hierarchies, and
make the postinst run mandb when run with the 'triggered' argument
(whose actions should normally be a subset of those performed on
'configure'). The rest is cleanup of older code that is now no longer
needed.
There are more complex ways to use triggers that could be used to
replace things like the update-menus lock in a smooth way by deferring
execution of a tool until the trigger is activated. See update-initramfs
in Ubuntu for an example of this:
if $USETRIGGERS \
test x$DPKG_MAINTSCRIPT_PACKAGE != x \
test $# = 1 \
test x$1 = x-u \
dpkg-trigger --check-supported 2/dev/null
then
if dpkg-trigger --no-await update-initramfs; then
echo update-initramfs: deferring update (trigger activated)
exit 0
fi
fi
But at this point Ian should field any further questions, I think; I've
only looked into this superficially because AIUI that sort of trick is
only necessary if you have a slow tool that lots of postinsts already
call and you want to stop them doing so even before you've changed all
the postinsts. I don't think we typically need this for migrating things
like debhelper - if a tool is idempotent we can often enough just make
it be triggered by changes to the relevant directory, drop the debhelper
autoscript, and let packages be rebuilt in the normal course of events.
--
Colin Watson [EMAIL PROTECTED]
Index: debian/man-db.triggers
===
--- debian/man-db.triggers (revision 0)
+++ debian/man-db.triggers (revision 0)
@@ -0,0 +1,9 @@
+# Several of these directories are not expected to be used in
+# policy-compliant packages, but they're listed in our default
+# /etc/manpath.config so we register interest in them for completeness.
+interest /usr/man
+interest /usr/share/man
+interest /usr/local/man
+interest /usr/local/share/man
+interest /usr/X11R6/man
+interest /opt/man
Index: debian/postinst
===
--- debian/postinst (revision 2503)
+++ debian/postinst (working copy)
@@ -1,5 +1,17 @@
#!/bin/sh -e
+run_mandb () {
+perl -e '@pwd = getpwnam(man); $( = $) = $pwd[3]; $ = $ = $pwd[2];
+ exec /usr/bin/mandb, @ARGV' -- $@ || true
+}
+
+if [ $1 = triggered ]; then
+# We don't print a status message here, as dpkg already said
+# Processing triggers for man-db
+run_mandb -pq
+exit 0
+fi
+
[ $1 = configure ] || exit 0
oldcatdir=/var/catman
@@ -71,56 +83,37 @@
if dpkg --compare-versions $2 lt 2.3.16 || \
([ ! -f $catdir/index.db ] [ ! -f $catdir/index.bt ]); then
-# If the build-database question was never asked, this is probably a
-# fresh install, or maybe we're reconfiguring. The default is to build
-# the database.
-db_fget man-db/build-database seen
-if [ $RET = false ]; then
- build_db=1
-else
- # This should probably only fire when upgrading from less than
- # 2.3.16, but it doesn't really matter.
- db_get man-db/build-database
- if [ $RET = true ]; then
- build_db=1
- fi
-fi
+# All versions before 2.3.17.1-1 removed cat page hierarchies on
+# upgrade. Since then a preinst hack means upgrades from 2.3.16 or later
+# won't do this, but the hack is nasty enough that I don't want to
+# extend it back beyond then. Thus, we need to build the database from
+# scratch on old upgrades. This also covers fresh installs.
+build_db=1
elif dpkg --compare-versions $2 lt 2.4.2-1; then
+# At 2.3.17.1-5, the database version number changed to 2.3.2.
+# At 2.4.0-1, the database version number changed to 2.4.1 and we
+# moved from libdb2 to libdb3.
+# At 2.4.2-1, we moved from libdb3 to libgdbm3.
+build_db=1
+
# Clean up old btree databases from before 2.4.2-1. They're useless now.
find /var/cache/man -name index.bt -print0 | xargs -0r rm -f
-
-db_get man-db/rebuild-database
-if [ $RET =
Re: Triggers status?
On Wed, Oct 10, 2007 at 12:44:07AM -0500, Manoj Srivastava wrote: Manoj Srivastava writes (Re: Triggers status?): I also would love to have a pre-install trigger [...] to ensure that a SELinux policy for a package is loaded before the package is unpacked; Well, when one or more packages are going to be installed a not trigger but something that walks like a trigger, sounds like a trigger goes off, So, afaics, Ian's triggers provide fairly weak ordering by time -- they'll delay marking a package as installed a little bit, and consequent postinst runs, but that's it. Delaying the unpack phase is a bigger step. The above also seems different in that triggers are mostly about aggregating similar tasks (update-menus for foo, update-menus for bar) so they can all be run at once, substantially quicker. That doesn't seem to be the case for SELinux policies either, which I presume would get lost in the noise of unpacking anyway. I'll be happy to call it a pre-install hook. That sounds sensible. I wonder if it'd be possible to setup an SELinux policy so that dpkg is only able to unpack files that are already known about by SELinux -- at least that way you'd get an error on unpack, with dpkg's usual bail-out attempts, rather than a possible hole introduced into your system. Cheers, aj signature.asc Description: Digital signature
Re: Triggers status?
On Sun, Oct 21, 2007 at 02:13:59PM +0100, Colin Watson wrote: Is there a quick intro to using the triggers implementation anywhere around (this list's archives, maybe)? Or would you care to give a quick intro? Ian's final design is here and has a worked example: http://lists.debian.org/debian-dpkg/2007/04/msg00076.html I've attached my patch for man-db to make it use triggers, [...] Heh, neither of which are really terribly /quick/... minus the changes to debian/po/*. Basically, I install a 'triggers' control file registering interest in all the manual page directory hierarchies, and make the postinst run mandb when run with the 'triggered' argument So, two sorts of packages -- ones that activate a trigger, and ones that implement it (aka are interested in it). Packages activate a trigger by (a) just installing a file, no postinst needed, or (b) invoking dpkg-trigger from a maintainer script, or (c) having an activate entry in the triggers control file. AFAICT this puts the package into a triggers-awaited state and means it doesn't satisfy Depends:. When the trigger is eventually undertaken by the implementing package, it'll switch from triggers-awaited to installed. Packages implement a trigger by having an interest entry in the triggers control file, and having their postinst implement the trigger when invoked with triggered as the first argument, and all the trigger names, separated by spaces, as the second argument. When a trigger is activated, the implementing package will go from the installed state to trigger-pending, but continue to satisfy Depends:. AFAICS, this means that if you have three packages: I - implements trigger foo A - activates trigger foo B - depends: A, activates trigger foo in postinst then dpkg will: unpack I, A, B configure I, I = installed configure A, activate foo, A = trigger-await, I = trigger-pending can't configure B because A doesn't satisfy Depends I.postinst triggered foo, A = installed, I = installed configure B, activate foo, B = trigger-await, I = trigger-pending I.postinst triggered foo, B = installed, I = installed done But if B had activated foo by just installing a file or just an entry in its triggers control file, it would have been: unpack I, A, B configure I, I = installed configure A, activate foo, A = trigger-await, I = trigger-pending configure B, activate foo, A,B = trigger-await, I = trigger-pending I.postinst triggered foo, A,B,I = installed done If you have dependency chains of packages with postinsts and a common trigger, it seems like you devolve to the current case of running the triggered code once per-package, which seems a shame. I would have thought the common case would have been for B's postinst to be able to be run prior to the trigger happening for its dependency, A, but afaics there's no way that A can indicate that -- basically to say this trigger is relevant, but if it fails, I don't break at all, so that A can be installed immediately and stay that way, even if the I package later ends up in config-failed if the trigger doesn't end up working. Maybe invoking the trigger from B's preinst could work as a hack, but I don't see any indication you could rely on a trigger activated in preinst not being run prior to unpacking. In any event, that means that conceptually, triggers are the very last part of a package's postinst. dpkg uses the /var/lib/dpkg/triggers/ directory to manage state, with File - being a list of file/dir triggers, of the form $path $pkg\n Deferred - is a queue for trigger activations that haven't yet been put in /var/lib/dpkg/status Lock - is a lockfile Other files in that directory are named after explicit triggers directly, and are a list of interested packages, one perline. Explicit triggers follow the package name convention so are limited to lower case letters, digits, plus, minus and dot. Presumably this is hardcoded to prevent conflicts with the File/Deferred/Lock files in the same directoy. So the worst I could say about this is: a) there's no way of indicating triggers are optional to an activating package b) interested seems a confusing way to describe the packages that end up doing all the actual work to implement a trigger Obviously I haven't looked at the code, but I presume the worst thing there would be the indentation choices... :-P (a) could be fixed in the future just by changing the code, so doesn't seem a major issue. (b) is just an explanation issue. If the design is right, then it's just a matter of fixing any problems with the code, which can also happen over time afaics, so given this: a) speeds up installations/upgrades significantly by not duplicating work; and b) simplifies packaging by removing lots
Re: Triggers status?
On Mon, 22 Oct 2007 07:01:33 +1000, Anthony Towns [EMAIL PROTECTED] said: I wonder if it'd be possible to setup an SELinux policy so that dpkg is only able to unpack files that are already known about by SELinux -- at least that way you'd get an error on unpack, with dpkg's usual bail-out attempts, rather than a possible hole introduced into your system. That would be nice (the error on unpack, that is) -- but is hard to do: not all packages have a specific policy (indeed, this is the only sane scenario: 10,000 policy modules for Debian would be untenable). Nice, but not required for security, really -- since the default is to install the files with no special security domain, and no domain transitions on execution; so lacking a security policy you get a bog-common initial security domain, with no special privileges. This is because the default is to deny by default -- and thus security policy modules _add_ the permissions for special tasks that packages need to do. Lacking security policy does not mean you have a security hole -- it means that the package you installed might not have the permissions to do anything useful, perhaps including running stuff in the postinst (remember, running as root/apt_t does not buy you as much in a SELinux machine as running with root on a non-selinux box does). I'm trying to increase functionality with the pre-install hook, security is not the driver here. manoj -- ... Had this been an actual emergency, we would have fled in terror, and you would not have been informed. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Thu, Oct 11, 2007 at 05:34:50AM +0300, Guillem Jover wrote: On Tue, 2007-10-09 at 19:01:53 +0100, Ian Jackson wrote: Colin Watson writes (Triggers status?): I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. The implementation of triggers is not going to change incompatibly. It's well-tested now in Ubuntu and should just be merged into Debian's dpkg. Err, well of course it's highly desirable to not do such kind of changes without good reason, but I don't think the fact that it has been deployed in a derivative distro means that we should blindly merge any such code drops without review and/or possible changes. Do you have any estimates as to when such a review might be likely to happen? I appreciate that it is of course dependent on people's free time, as always; it's just that I feel rather blocked on this and there doesn't seem to be any movement at all. I would understand the delay if there were some major problem that had been identified - but it all seems to work and it's a substantial advance that would let me simplify a bunch of stuff, so please forgive my impatience. :-) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Guillem Jover writes (Re: Triggers status?): Err, well of course it's highly desirable to not do such kind of changes without good reason, but I don't think the fact that it has been deployed in a derivative distro means that we should blindly merge any such code drops without review and/or possible changes. Don't be ridiculous. This is offensive to me personally. This code has been * designed with extensive input from this mailing list in Debian fora * written by dpkg's original maintainer * tested extensively * available for merging for several months Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Tue, 2007-10-09 at 19:01:53 +0100, Ian Jackson wrote: Colin Watson writes (Triggers status?): I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. The implementation of triggers is not going to change incompatibly. It's well-tested now in Ubuntu and should just be merged into Debian's dpkg. Err, well of course it's highly desirable to not do such kind of changes without good reason, but I don't think the fact that it has been deployed in a derivative distro means that we should blindly merge any such code drops without review and/or possible changes. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Colin Watson writes (Triggers status?): I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. The implementation of triggers is not going to change incompatibly. It's well-tested now in Ubuntu and should just be merged into Debian's dpkg. I think you should just upload your man-db change to Debian. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Manoj Srivastava writes (Re: Triggers status?): I also would love to have a pre-install trigger (which I think is not present in the current patch; I'll be working on that) to ensure that a SELinux policy for a package is loaded before the package in unpacked; so that dpkg would be aware of initial security contects for files and directories before we unpack a package for the first time. This is (a) a bad idea as previously discussed and (b) not at all like what is now called a trigger so please call it something different. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Tue, 9 Oct 2007 19:02:38 +0100, Ian Jackson [EMAIL PROTECTED] said: Manoj Srivastava writes (Re: Triggers status?): I also would love to have a pre-install trigger (which I think is not present in the current patch; I'll be working on that) to ensure that a SELinux policy for a package is loaded before the package in unpacked; so that dpkg would be aware of initial security contects for files and directories before we unpack a package for the first time. This is (a) a bad idea as previously discussed Well, no. You think it is a bad idea; I do not think that makes it so. and (b) not at all like what is now called a trigger so please call it something different. Well, when one or more packages are going to be installed a not trigger but something that walks like a trigger, sounds like a trigger goes off, and calls a utility function with the names of the packages going to be installed (so, goes off in the pre-install phase), and this utility function ensure that the security policy is in place before the packages get unpacked. I don't care what this is called; as long as it gets invoked. I'll be happy to call it a pre-install hook. manoj -- Every solution breeds new problems. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Triggers status?
Hi, I was wondering what the status of merging Ian's triggers work is; I can't find any comments by the dpkg maintainers on it. I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Colin Watson wrote: I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. I have a fairly vast number of things that I want to use triggers for in debhelper.. -- see shy jo signature.asc Description: Digital signature
Re: Triggers status?
On Sun, 7 Oct 2007 10:13:45 -0400, Joey Hess [EMAIL PROTECTED] said: Colin Watson wrote: I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. I have a fairly vast number of things that I want to use triggers for in debhelper.. I also would love to have a pre-install trigger (which I think is not present in the current patch; I'll be working on that) to ensure that a SELinux policy for a package is loaded before the package in unpacked; so that dpkg would be aware of initial security contects for files and directories before we unpack a package for the first time. manoj -- Linux: the operating system with a CLUE... Command Line User Environment. (seen in a posting in comp.software.testing) Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
