Re: Finding out in postinst whether some other package is configured
Goswin von Brederlow wrote: > In the past people have suggested adding something to dpkg that allows > one to schedule a script to be run _once_ at the end of a dpkg > session. E.g. every tex font package would call: > > dpkg-run-once /usr/share/tetex-bin/update-fonts It'd have to be once, before any dependent packages are configured, otherwise "configured" no longer means "ready for use", and you'd need to implement a Depends-No-Really-I-Mean-It: field. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
Frank Küster <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > >> Frank Küster <[EMAIL PROTECTED]> writes: >> >>> Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >>> Also how would a package inset such a Post-Invoke line into the conffig? Modifying the conffile would be a policy violation. >>> >>> The package that provides the hook to run provides the config entry; the >>> packages that need to run the hook touch a file in /var/ or >>> append a line to such a file. >> >> That means that every such case has to reinvent the wheel. >> >> Also you still haven't gotten the hook into the Post-Invoke apt >> option. > > I don't remember how zope does it, but apparently it has found a way. > Probably it just drops a file into apt/conf.d, not caring about other > files specifying a Post-Invoke option (which works because there are > none...) Yes, that is usualy done. But it won't work the first time around. Only subsequent apt calls would work. And dpkg -i foo.deb also ignores those. So not realy an option. > Regards, Frank > -- > Frank Küster > Inst. f. Biochemie der Univ. Zürich > Debian Developer MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Frank Küster <[EMAIL PROTECTED]> writes: > >> Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> >>> Also how would a package inset such a Post-Invoke line into the >>> conffig? Modifying the conffile would be a policy violation. >> >> The package that provides the hook to run provides the config entry; the >> packages that need to run the hook touch a file in /var/ or >> append a line to such a file. > > That means that every such case has to reinvent the wheel. > > Also you still haven't gotten the hook into the Post-Invoke apt > option. I don't remember how zope does it, but apparently it has found a way. Probably it just drops a file into apt/conf.d, not caring about other files specifying a Post-Invoke option (which works because there are none...) Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Finding out in postinst whether some other package is configured
Frank Küster <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > >> Also how would a package inset such a Post-Invoke line into the >> conffig? Modifying the conffile would be a policy violation. > > The package that provides the hook to run provides the config entry; the > packages that need to run the hook touch a file in /var/ or > append a line to such a file. That means that every such case has to reinvent the wheel. Also you still haven't gotten the hook into the Post-Invoke apt option. >>> The big problem with that is that if such a command ever fails, how does >>> the package system know which package caused the error? It could be the >>> one that first registered the call, but also an other package that would >>> have added it to the journal if it hadn't been there yet. >> >> Probably all of them instead of just one. >> >> I don't see this as a big problem. Currently if one of the packages >> adds broken files causing the update script to fail on average half >> the packages will be broken (everything after the broken one). >> >> So having them all set to failed is just twice as bad from a statistic >> point of view and doesn't create any extra work. > > You forget the extra work of the user (and the admin of the wrongly > blamed package) to find out which package is responsible. With the > current setup, you just need to look at dpkg's output and check which > package was first to fail. Ok. If the error message sucks and doesn't reveal the culprit then you have a point. > Regards, Frank MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
Op ma, 17-10-2005 te 16:17 +0200, schreef Frank Küster: > Hi Wouter, > > thanks for your answer - did you reply to me instead to the list on > purpose? Uh, no -- sorry. > If you want, you can cite me on the list. Here goes :) > Wouter Verhelst <[EMAIL PROTECTED]> wrote: > > >> The big problem with that is that if such a command ever fails, how does > >> the package system know which package caused the error? It could be the > >> one that first registered the call, but also an other package that would > >> have added it to the journal if it hadn't been there yet. > > > > How is that worse than the current situation? > > > > Consider: > > > > apt-get install xfonts-* > > > > They all run something to update the fonts. The first one did something > > wrong, so its postinst fails on updating the fonts, and the package is > > marked as unconfigured (or is it half-configured? not sure). > > > > The next package, however, tries to run the same command (updating the > > font cache), but the files from the first package are /still/ there. > > Hence, its postinst also fails, and this package is also marked as > > half-/unconfigured. > > > > The proposed situation would basically result in the same thing, with > > the exception that on average, the number of packages in a > > half-/unconfigured state would be larger. > > There's an other difference: By inspecting the dpkg log, it is currently > plain to see which package failed first. If all would be done in a > dpkg-post-run hook, it would require some debugging to even know which > package to blame. Putting this debugging load on the maintainer of an > arbitrary package the user chooses (and on the inexperienced user), > instead of the responsible maintainer, is not only "unjust", it is very > ineffective. > > > All that being said, I believe this problem can be solved. All examples > > I've seen where such a mechanism would be interesting involve > > regenerating some cache or other based on the added files by some > > packages. > > ACK. > > > Might it not be feasible to require that packages call the > > (hypothetical) dpkg-run-once command with the list of files it added; > > that the command which is actually ran once gets that list of files; and > > that if something goes wrong, it outputs the name(s) of the package(s) > > which made the run fail? > > I don't think so. E.g. in the case of mktexlsr and updmap-sys, two > candidates from the tetex-bin package, this wouldn't work (at least not > well). > > mktexlsr as provided by upstream just stores the "ls -R" output of a > directory tree in a ls-R file at the tree root. To work with a list of > added files, we would have to develop a completely new, Debian-specific > tool to edit these files. > > updmap-sys takes a configuration file (which has gotten some new lines > after the new package put a file in /etc/texmf/updmap.d/ and ran > update-updmap), checks whether all fonts referenced in the configuration > file are actually present, and generates a couple of font > "configuration" files of different syntax (for different programs) in > /var/lib/texmf/fonts. There's a sophisticated mechanism that makes sure > that files of removed-but-not-purged packages in the updmap.d directory > do no harm; this cannot be achieved easily when running a dpkg-post-run > hook with a list on the command line. > > Regards, Frank -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond
Re: Finding out in postinst whether some other package is configured
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Also how would a package inset such a Post-Invoke line into the > conffig? Modifying the conffile would be a policy violation. The package that provides the hook to run provides the config entry; the packages that need to run the hook touch a file in /var/ or append a line to such a file. >> The big problem with that is that if such a command ever fails, how does >> the package system know which package caused the error? It could be the >> one that first registered the call, but also an other package that would >> have added it to the journal if it hadn't been there yet. > > Probably all of them instead of just one. > > I don't see this as a big problem. Currently if one of the packages > adds broken files causing the update script to fail on average half > the packages will be broken (everything after the broken one). > > So having them all set to failed is just twice as bad from a statistic > point of view and doesn't create any extra work. You forget the extra work of the user (and the admin of the wrongly blamed package) to find out which package is responsible. With the current setup, you just need to look at dpkg's output and check which package was first to fail. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Finding out in postinst whether some other package is configured
Frank Küster <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > >> Anthony DeRobertis <[EMAIL PROTECTED]> writes: >> >>> Frank Küster wrote: >>> In the particular case, the reason is something else: If the recommended package B (tetex-bin) is there, it makes sense to run one of its executables (mktexlsr, updmap) to register the files of package A (any TeX font package). This is a time-consuming process. However, if B is installed but unconfigured, we can save this time because when B is configured, it will run these executables, anyway, and doing this also will pick up package A's files. >>> >>> Sounds to me like package B should be performing these optimizations, >>> not package A. >> >> In the past people have suggested adding something to dpkg that allows >> one to schedule a script to be run _once_ at the end of a dpkg >> session. > > This is already possible by using DPkg::Post-Invoke in apt.conf. The > zope packages do that, however I don't know what happens if a zope > package is installed with dpkg instead of apt/aptitude/whatever. Post-Invoke gets run every time so you need some more wraper magic to implement a run "this" just once but only when needed. Also how would a package inset such a Post-Invoke line into the conffig? Modifying the conffile would be a policy violation. >> dpkg-run-once would add the command to a journal (unless it already >> contains it) and dpkg would execute that journal at the end of its >> livetime. For use in apt/aptitude/dselect executing the journal could >> be suspended until the last dpkg run. > > The big problem with that is that if such a command ever fails, how does > the package system know which package caused the error? It could be the > one that first registered the call, but also an other package that would > have added it to the journal if it hadn't been there yet. Probably all of them instead of just one. I don't see this as a big problem. Currently if one of the packages adds broken files causing the update script to fail on average half the packages will be broken (everything after the broken one). So having them all set to failed is just twice as bad from a statistic point of view and doesn't create any extra work. > And even if you make a decision here, there's an other problem: Once > the call failed and you attributed this to a particular package, how do > you indicate this in the package system? Either by setting its state to > "unconfigured"; but this will then happen *after* packages that depend > on it have been (maybe successfully) configured. Or you have to invent > a new category. The run-once system would be for stuff with no depends on it. If something depends on such a command to be run then it is not garantied that _once_ is enough. One can easily create cases where the command must be run every time to satisfy the depends. But you are right. There could be a similar thing (an option) indicating this must be run at the end of a depends step instead at the end of dpkg or even multiple dpkg calls by apt. A simple and probably already quite effective solution would be to have packages stay unconfigured until their journal entry has been run but run it as late as possible (only if something depends on it or at the end). > Regards, Frank MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Anthony DeRobertis <[EMAIL PROTECTED]> writes: > >> Frank Küster wrote: >> >>> In the particular case, the reason is something else: If the recommended >>> package B (tetex-bin) is there, it makes sense to run one of its >>> executables (mktexlsr, updmap) to register the files of package A (any TeX >>> font package). This is a time-consuming process. However, if B is >>> installed but unconfigured, we can save this time because when B is >>> configured, it will run these executables, anyway, and doing this also >>> will pick up package A's files. >> >> Sounds to me like package B should be performing these optimizations, >> not package A. > > In the past people have suggested adding something to dpkg that allows > one to schedule a script to be run _once_ at the end of a dpkg > session. This is already possible by using DPkg::Post-Invoke in apt.conf. The zope packages do that, however I don't know what happens if a zope package is installed with dpkg instead of apt/aptitude/whatever. > dpkg-run-once would add the command to a journal (unless it already > contains it) and dpkg would execute that journal at the end of its > livetime. For use in apt/aptitude/dselect executing the journal could > be suspended until the last dpkg run. The big problem with that is that if such a command ever fails, how does the package system know which package caused the error? It could be the one that first registered the call, but also an other package that would have added it to the journal if it hadn't been there yet. And even if you make a decision here, there's an other problem: Once the call failed and you attributed this to a particular package, how do you indicate this in the package system? Either by setting its state to "unconfigured"; but this will then happen *after* packages that depend on it have been (maybe successfully) configured. Or you have to invent a new category. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Finding out in postinst whether some other package is configured
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > Frank Küster wrote: > >> In the particular case, the reason is something else: If the recommended >> package B (tetex-bin) is there, it makes sense to run one of its >> executables (mktexlsr, updmap) to register the files of package A (any TeX >> font package). This is a time-consuming process. However, if B is >> installed but unconfigured, we can save this time because when B is >> configured, it will run these executables, anyway, and doing this also >> will pick up package A's files. > > Sounds to me like package B should be performing these optimizations, > not package A. In the past people have suggested adding something to dpkg that allows one to schedule a script to be run _once_ at the end of a dpkg session. E.g. every tex font package would call: dpkg-run-once /usr/share/tetex-bin/update-fonts The same would work for manpages, info files, menu entries, ... whatever comes in chunks from multiple packages. dpkg-run-once would add the command to a journal (unless it already contains it) and dpkg would execute that journal at the end of its livetime. For use in apt/aptitude/dselect executing the journal could be suspended until the last dpkg run. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 14 octobre 2005 à 22:23 -0400, Anthony DeRobertis a écrit : >> Frank Küster wrote: >> >> > In the particular case, the reason is something else: If the recommended >> > package B (tetex-bin) is there, it makes sense to run one of its >> > executables (mktexlsr, updmap) to register the files of package A (any TeX >> > font package). This is a time-consuming process. However, if B is >> > installed but unconfigured, we can save this time because when B is >> > configured, it will run these executables, anyway, and doing this also >> > will pick up package A's files. > > Isn't it possible to run a consistency check, to know whether it is > necessary to re-run mktexlsr/updmap before actually running them? Such a check wouldn't be faster than running the actual script... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Finding out in postinst whether some other package is configured
Le vendredi 14 octobre 2005 à 22:23 -0400, Anthony DeRobertis a écrit : > Frank Küster wrote: > > > In the particular case, the reason is something else: If the recommended > > package B (tetex-bin) is there, it makes sense to run one of its > > executables (mktexlsr, updmap) to register the files of package A (any TeX > > font package). This is a time-consuming process. However, if B is > > installed but unconfigured, we can save this time because when B is > > configured, it will run these executables, anyway, and doing this also > > will pick up package A's files. Isn't it possible to run a consistency check, to know whether it is necessary to re-run mktexlsr/updmap before actually running them? > Sounds to me like package B should be performing these optimizations, > not package A. As there can be several "packages A", this is the kind of thing that should be done in all their postinsts. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: Finding out in postinst whether some other package is configured
Frank Küster wrote: > In the particular case, the reason is something else: If the recommended > package B (tetex-bin) is there, it makes sense to run one of its > executables (mktexlsr, updmap) to register the files of package A (any TeX > font package). This is a time-consuming process. However, if B is > installed but unconfigured, we can save this time because when B is > configured, it will run these executables, anyway, and doing this also > will pick up package A's files. Sounds to me like package B should be performing these optimizations, not package A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
Ben Armstrong <[EMAIL PROTECTED]> wrote:
> I don't know about an "established" way, but libc6.postinst looks
> interesting:
>
> # Only get the ones that are installed, and configured
> check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if
> ($1 ~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* installed$/) {
> print package }}')
Thanks, that looks very good. And it answers the question (or at least
gives a good indication) whether calling dpkg -s during a run of "dpkg
--install " gives a sensible output; otherwise
they'd probably know.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Re: Finding out in postinst whether some other package is configured
also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.2003 +0200]: > But this file will stay there if the user chooses to keep their changed > version. No, then it would be moved to *.dpkg-dist -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! "in the figure of the president, george w. bush, the incompetence, stupidity, and sheer inhumanity that characterize so much of america’s money-mad corporate elite find their quintessentially repulsive expression." -- journalist, aftermath of katrina signature.asc Description: Digital signature (GPG/PGP)
Re: Finding out in postinst whether some other package is configured
On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured?
Assuming your package does something reasonable with this knowledge ...
> Testing for file contents can only tell whether
> it is unpacked, but that might not be enough.
I don't know about an "established" way, but libc6.postinst looks
interesting:
# Only get the ones that are installed, and configured
check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if ($1
~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* installed$/) { print
package }}')
Ben
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
Ben Armstrong <[EMAIL PROTECTED]> wrote: > On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote: >> is there an established way to find out in the postinst script of a >> package whether an other package (e.g. one which we Recommend or >> Suggest) is configured? Testing for file contents can only tell whether >> it is unpacked, but that might not be enough. >> >> If there isn't, are there other people who felt the need to know this? > > I worry about why you would need to know this. I'm envisioning a > package "A" that has a particular default configuration if you install A > before B, but a different configuration if you install B before A. What > will the user be missing out on if they're installed in the "wrong" > order? And what corrective action can the user take? In the particular case, the reason is something else: If the recommended package B (tetex-bin) is there, it makes sense to run one of its executables (mktexlsr, updmap) to register the files of package A (any TeX font package). This is a time-consuming process. However, if B is installed but unconfigured, we can save this time because when B is configured, it will run these executables, anyway, and doing this also will pick up package A's files. While writing this, I get the feeling that I don't want to know this. I have been thinking about a mechanism to run these time-consuming processed with a dpkg-postinstallation hook as zope does for a long time. But I decided not to do this because they sometimes fail (99% because of user misconfiguration), and it's better to know which package was configured when it failed. For the same reason, I probably don't want to delay the registration process if tetex-bin isn't already configured. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Finding out in postinst whether some other package is configured
martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.1928 +0200]: >> is there an established way to find out in the postinst script of a >> package whether an other package (e.g. one which we Recommend or >> Suggest) is configured? Testing for file contents can only tell whether >> it is unpacked, but that might not be enough. > > Assuming it provides a conffile, can you check for $FILE.dpkg-new ? But this file will stay there if the user chooses to keep their changed version. So I would have to check for $FILE, too. But then I can't discriminate between "was removed but not purged, now it is unpacked but unconfigured" and "is configured but the user chose to keep the old changed conffile", can I? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Finding out in postinst whether some other package is configured
On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote: > is there an established way to find out in the postinst script of a > package whether an other package (e.g. one which we Recommend or > Suggest) is configured? Testing for file contents can only tell whether > it is unpacked, but that might not be enough. > > If there isn't, are there other people who felt the need to know this? I worry about why you would need to know this. I'm envisioning a package "A" that has a particular default configuration if you install A before B, but a different configuration if you install B before A. What will the user be missing out on if they're installed in the "wrong" order? And what corrective action can the user take? Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding out in postinst whether some other package is configured
also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.1928 +0200]: > is there an established way to find out in the postinst script of a > package whether an other package (e.g. one which we Recommend or > Suggest) is configured? Testing for file contents can only tell whether > it is unpacked, but that might not be enough. Assuming it provides a conffile, can you check for $FILE.dpkg-new ? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! "i am a deeply superficial person." -- andy warhol signature.asc Description: Digital signature (GPG/PGP)
