Dear Christian and Justin, Thank you very much for your help with translating and improving package description and debconf dialogs. I much appreciate your fantastic approach to the task and the amount of attention that you and all the translators dedicated to my relatively unimportant package with pretty low popcon score.
Also please let me apologise for not being able to respond in the timely
manner. I am very grateful for all improvements and feedback.
I see that this very special package of mine caused a lot of confusion
so I'll try to answer some questions and hopefully spread some light on how it
works.
> If people are really doing "apt-get install fheroes2-pkg" and then
> being surprised by this information (to the point that they say "no"),
> it seems to me you need a better package description!
>
> And then fheroes2-pkg/first-install seems to unconditionally perform
> the same song and dance all over again. Why?
Indeed it seems unnecessary and in fact early revisions of this package did
not do much of a dance. However ftp-masters insisted on adding extra dialogs
to prevent this package from installing script (which is running at the end of
every apt-get operation) without user's consent.
####
> > + Please remember to run "sudo dpkg-reconfigure ${PKGI}"
> > to build and install guest package(s) for the first time.
>
> It's grammatical, but I don't understand it. What "guest
> package(s)" is it talking about? Why don't we know if they're
> singular or plural? If it's talking about the same fheroes2 package
> that it just claimed to be about to download/compile/install, why is
> it now telling me that this won't happen yet? *When* do I need to
> "remember" to run this command?
This package is meant to be a proof of concept for a new approach to make an
installer. The package description, build scripts and debconf system are meant
to be maintained separately with some degree of abstraction from guest
packages to allow re-use of such distribution system between several packages.
For example the general convention would be "fheroes2-pkg" for "host" package;
"fheroes2" for guest source package (i.e. software) which builds into one or
more guest binary packages (e.g. "fheroes2", "fheroes2-data" etc.).
Although fheroes2-pkg builds only one guest binary package, the build system
is designed to handle "guest" library producing multiple binary packages.
Therefore prompt for "downloading and compiling ${PKGG}${VER}?" refers to
guest source package or "software".
I've change "build" template description to the following:
The installation process is therefore about to download the source files
from SourceForge, compile them, and install the binary deb package(s)
[${PKGG_ALL}].
So dialog contains information about what binary packages are going to be
(built and) installed even though it might be just one binary package.
Now the interesting part: installer can build guest packages from post-install
Apt hook which (if installed as per user's decision) will have a chance to run
only on next apt-get invocation. This means that when "fheroes2-pkg" is
installed, guest package(s) are not generated. User is therefore advised to
run "sudo dpkg-reconfigure fheroes2-pkg" to build guest package(s).
If user gave consent to install Apt post-invoke hook then on next apt-get
operation script will check whether guest packages are installed and
build/install 'em if necessary.
The idea behind this approach is to handle upgrades gracefully and re-build
guest packages as soon as host package is upgraded. Unfortunately due to
technical limitations it is not possible to make guest packages on first
install without "dpkg-reconfigure fheroes2-pkg" which is also necessary in
case when Apt post-invoke hook in not active.
> > An update to guest package(s) [${PKGG_ALL}] version ${VER} is available
> > but automatic upgrade is disabled.
>
> We know the name(s) and we know the version (which is the same for all
> of them) but we don't know whether it's a package or packages?
That's right, as long as we use variable to substitute with names of the guest
package(s) perhaps it make sense to avoid hardcoding the number of packages.
I understand that it may complicate translations but hopefully in the end
there will be less work for translators if we'll be able to re-use
translations among similar packages. As you can see I really like the idea of
using variables to refer to package names in debconf template...
####
> But I still don't understand what these "host" and "guest" packages
> are. Does it mean the installer (this very package doing the
> talking) is the "host" and the fheroes2 package is the "guest"? If
> so, when are there ever plural guests?
Depending of whether we're talking about source package (i.e. software) or
binary deb packages (in case there are more than one).
> And if we already know the
> package-names, why are we going to such lengths to avoid mentioning
> them?
Please keep in mind that build system may produce a different number of binary
packages depending on architecture so we may not know beforehand how many
packages will be built. (This is only theoretical possibility as "fheroes2-
pkg" always builds "fheroes2" binary package on all architectures).
####
Install/Remove APT post-invoke hook?
If activated, the APT post-invoke hook takes care of future automatic
upgrades of guest package(s) on host package upgrade. When an update
is available, the hook will attempt to download and build the package(s),
and (if "apt-get check" reports no errors) install them with "dpkg -i".
.
Alternatively, guest package(s) can be built by manual invocation of
"dpkg-reconfigure ${PKGI}".
> Why is it telling us this now? I gather we'll only see this if
> we've got the hook installed, so haven't we already read this (and
> seen the hook in action)? At present the post-invoke_hook-install
> and post-invoke_hook-remove templates are different only in the
> first word of the short Description. This one really ought to say
> something like:
>
> If the hook is disabled, no automatic upgrades will occur.
>
> But I'm too uncertain about what's going on to change it.
This is new package and indeed there might be some improvements to dialogs.
IMHO two dialogs are needed to highlight hook's current status.
We could say just "If the hook is disabled, no automatic upgrades will occur."
but would it be sufficient to decide what to choose? User may not be aware of
a particular behaviour and so I'm just trying to be clear of what is going to
happen.
> But I didn't insist, since I'm not convinced I understand what's going
> on here with these "host" and "guest" packages. If anybody does,
> please explain it to me!
There are "README.Debian" and "README.source" files where the concept of a
package installing encapsulated package is described. As always documentation
can be improved but I should be happy to explain the missing bits if you have
any questions.
Thank you.
--
Regards,
Dmitry Smirnov
GPG key : 4096R/53968D1B
signature.asc
Description: This is a digitally signed message part.
