Re: Bug#725467: fheroes2-pkg: General update after the debconf review process
Dmitry Smirnov wrote:
> Also please let me apologise for not being able to respond in the timely
> manner. I am very grateful for all improvements and feedback.
(Looks in mailbox... checks further back... greps through last year's
mail archives... oh, this was October 2013! So my apologies if I've
forgotten even the small amount I worked out the first time around...)
> 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.
The thing is, I suspect you really do need a clearer package
description, since I don't see anything there that would make me
expect it to have an APT hook. It's all very well having explanations
in the package's README files, but users don't get to read the stuff
under /usr/share/doc/$PKG until after they've installed $PKG! The
only information that's available when they're reading the debconf
dialogue is that dialogue plus whatever they remember from the package
description... assuming they even bothered to read that.
> ####
>
>>> + 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.).
Why do you call them "host" and "guest" packages? That's terminology
from VMs, and I don't see how it relates to package building. If you
called the autobuilder package "fheroes2-builder" or "fheroes2-master"
or something, and referred to the relationship as "builder/client" or
"master/slave" or something, that would make some kind of sense to me.
But "guest" just makes me wonder where fheroes2 was before it came and
visited the "host".
Are there any comparable setups already in the archives? equivs,
dkms... unfortunately none of them seem much help, though DKMS does
suggest the option of just inventing your own acronym.
> 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".
Well, aren't people going to need to rewrite the template to insert
the name of the other "host" package? Can't we rely on them to make
things plural when necessary?
Alternatively, instead of talking about the individual package(s), you
might want to introduce the idea of a set of guest(/slave/whatever)
packages. If the host(/master/whatever) package is going to update
the entire set every time, talking about the set (or maybe "suite") is
always singular. But that seems overcomplicated for now.
Or maybe there's some way of evading it by always using words like
"sources" and/or "software" rather than "package(s)".
> 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.
I suppose here you could say
The installation process is therefore about to download the source files
from SourceForge, compile them into binary deb package format, and install
the output (${PKGG_ALL}).
> 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).
Does this hook run every time my nightly cronjobs run "apt-get update"
or only when I upgrade the autobuilder package? (I think the answer
is something like "whenever APT invokes dpkg", but you can't expect
random end users to be familiar with packaging internals like this.)
Oh, and does the autobuilder routinely execute scripts downloaded from
an external source as root, or does it have its own UID and run build
processes under fakeroot?
> 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.
(What happens if the new version has new build-deps? What happens if
you trigger another rebuild before the first has finished?)
> 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.
It seems odd that you'd integrate it all into the dpkg scripts rather
than splitting it out as a /usr/(s)bin/fheroes2-autobuild tool - or
indeed (if you're planning to turn this into a generic automated
installer) a tool invoked as something like "autopkg build fheroes2".
>>> 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...
An avoiding-the-issue phrasing:
An upgrade to version ${VER} is available for the software managed by
fheroes2-pkg (${PKGG_ALL}), but automatic upgrades are disabled.
[...]
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: