Bug#793937: [RFR] templates://libdvd-pkg/{templates}

Wed Aug 12 11:13:46 UTC 2015

On Wednesday 12 August 2015 11:23:13 Justin B Rye wrote:
> > - compile them and install the binary deb package(s)
> > + compiles them and installs the binary deb package(s)
> > 
> >   [${PKGG_ALL}].
> >   .
> >   Please remember to run "sudo dpkg-reconfigure ${PKGI}"
> > 
> > Spelling error fix
> 
> I gather we're letting this get away with being a debconf note on the
> basis that it's essential that users get this information.

Yes, I believe this note is necessary.

> But in that case, why are these templates so resolutely uninformative?

What do you mean?

> Surely the maintainer knows whether "the binary deb package(s)" are
> singular or plural?

Actually those debconf dialogs are meant to be package independent.
We already have two packages implementing this concept
(libdvd-pkg, fheroes2-pkg) and I'd like to share (most of) debconf messages 
between them. This may be even more useful in long term if there will be any 
more packages of that kind.
It is not that easy to know beforehand whether "host" package build single or 
few "guest" packages. It may depend on architecture hence the intention is to 
preserve structures that can allow variations depending on circumstances.

> Why is it asking me to *remember* to do a thing
> that I've obviously never yet been given a reason to believe I need
> to do in the first place?  And why *is* it necessary?

Host package can not install guest package during normal DPKG operation as 
there is no way to inject something into DPKG transaction. On first install 
user is given a choice whether to allow seamless package upgrades in the 
future. When dialog is shown we don't know if DPKG database is locked by 
ongoing operations of if it is possible to build package right away like when 
"dpkg-reconfigure" is manually issued. If user agrees on installing APT post-
invoke hook then no additional dialogs are shown. If user decides not to 
allow seamless upgrades then we have to notify about (necessary) manual 
reconfiguration -- otherwise nothing will happen.

> And then this template is immediately followed by libdvd-pkg/build,
> which (apparently) also gets shown under exactly the same
> circumstances and also contains the reminder to run dpkg-reconfigure.

It should not be shown under same circumstances. At least that's not the 
intention.

> So why couldn't the information above have been incorporated into that
> template instead?

What information? Sorry I'm a bit lost here...

> Also, I would add a serial comma and throw out the meaningless use of
> square brackets.

I insist on preserving square brackets please. I completely trust you with 
commas.

> Still it's acting as if the maintainer doesn't know how many packages
> are involved.

Intentionally. We may build certain binary package only on certain 
architectures.

> If there's a -dev library involved here and end users
> don't get to opt out of building it, that seems like a major bug.

Why is that? Do you think we need to introduce more debconf prompts to ask 
user about which particular binary packages to build? Isn't there  already 
enough complexity?

> It goes on to say:
> >   Please remember to run "sudo dpkg-reconfigure ${PKGI}"
> >   to build and install guest package(s) for the first time.
> 
> Wait, what?  I just said it was okay to do that, didn't I?  So why am
> I now being told it won't happen unless I run it manually?  Or is it
> saying that I'll need to do it manually *unless* I let it happen
> automatically?

Due to technical reasons it is not possible to build guest packages 
automatically on first install. If you allow to build 'em it will happen 
later on next APT operation (which can happen much later). If you don't want 
to wait you need to run command manually.

> If ${PKGI} is always going to mean libdvd-pkg, why is it a variable?

Because host package is basically an envelope or template for delivering 
guest package(s). I want host package to have as little of its own 
customisations as possible. Partially to spare you from repeatedly 
translating similar packages.

> And... "guest packages"?  Uh-oh - I recognise this.  It's another
> instance of that unintelligible autobuilder framework that I couldn't
> make head or tail of in October 2013 (through to October 2014!) -
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725467

Yes, that's the one. I'm sorry for you troubles and I apologise for not being 
able to promptly reply to your inquiry regarding fheroes2-pkg.

> I *think* it ought to be something like this:
> 
>    _Description: Proceed with building ${PKGG}${VER}?
>     This package downloads the ${PKGG} source files from videolan.org,
>     compiles them, and installs the binary deb package
>     ${PKGG_ALL}.
>     .
>     Please indicate whether this process should go ahead now.
>     .
>     Alternatively, the download, compilation, and installation process can
>     be launched manually by running "sudo dpkg-reconfigure ${PKGI}".
> 
> Then *another* debconf note:
> >   Template: libdvd-pkg/upgrade
> >   Type: note
> >   
> >   _Description:
> >    An update to guest package(s) [${PKGG_ALL}] version ${VER} is
> >    available
> >    but automatic upgrades are disabled.
> >    .
> >    Please remember to run "sudo dpkg-reconfigure ${PKGI}" to build and
> >    install guest package(s) or consider installing the APT post-invoke
> >    hook.
> 
> What, so even if I tell it *not* to install the hook it'll bother me
> with a debconf note any time there happens to be an update?  It seems
> to me if it's going to nag me like that it might as well offer to do
> the one-off autoinstall every time, too.

It will not tell you when update is available if you authorise installation 
of post-invoke hook. Otherwise it will tell you to run dpkg-reconfigure to 
manually build guest packages once update is available. Easy.

> (Ah, but I suppose I could stop the installer nagging me by
> uninstalling it?  After all, I don't want to have to keep the whole of
> build-essential permanently installed on my non-developer desktop just
> so that I have the option of watching a DVD once every few years.)

Admittedly there are limitations to this approach. Feel free to propose 
improvements in another bug.

> If installing the APT post-invoke hook *also* requires me to run
> "sudo dpkg-reconfigure ${PKGI}" then the final paragraph needs to be
> rephrased.

It does not requires, but merely tells you that you might want to do so.

> I'm not letting it get away with this gibberish terminology of "guest
> packages".  There's no hosting setup here, and there's no implication
> that my guests are going to leave at some stage while the host stays -
> if anything the reverse is more likely.  We might as well call them
> "marmoset packages".  That doesn't mean anything either, but after
> dealing with all this stuff I'd prefer to be thinking about marmosets.

I understand that you have little appreciation to this obviously non-ideal 
approach of delivering guest packages. But please spare me from your 
criticism as IMHO alternative "installer" packages that don't bother 
generating proper "guest" packages are worse. 

> Again the process is summarised to only two items: "to download and
> build", but then not install?  If not, what does it do with them?

I'm a bit lost here but in theory one might copy packages to another machine 
manually...

> How about:
> 
>    _Description: Enable automatic upgrades for ${PKGG}?
>     If activated, the APT post-invoke hook takes care of future automatic
>     upgrades of autocompiled software on upgrades of the installer
>     package. When updates are available, the hook will attempt the
>     appropriate source downloads and package recompilations, and (if
>     "apt-get check" reports no errors) will install the packages with
>     "dpkg -i".

No, no no. Upgrade of installer (i.e. "host") package is not necessary means 
re-compilation of guest packages. Also I believe unnecessary technical 
details regarding particular implementation of check for DPKG database lock 
do not belong to debconf dialog. Please let's keep dialogs simple and 
introduce minimum changes, especially if you don't understand well enough how 
it works.

> > - packages that are necessary to play all video DVDs with media
> > - player of your choice (like VLC, SMplayer, Totem, etc.).
> > + packages that are necessary to play all video DVDs with any media
> > + player (such as VLC, SMplayer, Totem, etc.).
> > 
> > avoid "of your choice"....

Please be aware that you are touching a sensitive matters here. We need to 
tell about video players because this package alone is not sufficient to play 
video. Please check git repository for updates of this description -- it was 
edited many times as per output from many DDs and then approved by ftp-
masters and by legal review. Long package description is better left alone.

> The one thing users *don't* really need to be told here is that video
> DVDs can be played with a variety of media players.  Listing them just
> means you'll have to update this text every couple of years as
> desktops change their minds about which one to use.

I'm with you here but I don't know a better way to articulate the previous 
argument without mentioning players. I'm happy to mention generic "player" or 
"players" without mentioning any particular ones.

> And this description has the same problem that descriptions for
> installer packages always seem to have: it doesn't tell me *why* it's
> only an installer.  It ought to start with something like
> 
>     Description: DVD-Video playing library - installer
>      Some features of the DVD-Video format require the use of software
>      to bypass the Content Scramble System (CSS), which cannot be
>      distributed via the Debian repositories.

Due to legal reasons this can not be mentioned. This package was in 
preparation for over two years precisely because such description can't be 
used. Check early commits to repository and you'll see that something like 
that was originally meant to be used. Unfortunately reality does not allow 
such description.

> Wait a minute... there are package descriptions for the marmoset
> package(s) in libdvd-pkg/libdvd-pkg-1.3.99-1libdvdcss/debian/control,
> and it turns out there *are* two of them, libdvdcss2 and
> libdvdcss-dev.  Maintainer?  Hello?

Yes, two guest packages. I don't understand your question.

-- 
Cheers,
 Dmitry Smirnov.

---

You have to start with the truth. The truth is the only way that we can
get anywhere. Because any decision-making that is based upon lies or
ignorance can't lead to a good conclusion.
        -- Julian Assange, 2010
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150812/f941266c/attachment-0001.sig>