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

[Justin B Rye]

Dmitry Smirnov wrote:
> 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?

Put it this way: not many debconf reviews end with the maintainers
insisting they're legally obliged to keep secret the first thing users
are going to want to know about the package!

>> Surely the maintainer knows whether "the binary deb package(s)" are
>> singular or plural?
> 
> Actually those debconf dialogs are meant to be package independent.

That seems unfriendly.  It's not as if users are likely to see
fheroes2 and libdvdcss as forming a natural set... all they know is
that the dialogues are mysteriously unclear about things the
maintainer should have no trouble telling them about.  One of the
things I suggested last time round that probably got lost was that if
we *really* need to be vague about whether it's singular or plural,
the obvious word to use is "software".  Or it could be something like

   This package downloads the sourcecode for ${PKGM} from ${UPSTREAM},
   compiles it into binary deb package format, and installs the output
   (${PKGM_ALL}).

> 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.

Well, I may be making your life annoying right now, but if it's a good
robust framework then good luck to it.  The last installer-package that
passed through d-l-e this week had much bigger problems than commas in
the wrong place!

> 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.

If it's unlikely to matter for this package, I'd recommend taking the
confusing explicitly-uninformative uses of "(s)" out of the templates.
If it *might* matter, I still recommend getting rid of them, but in this
case it would be worth doing the work to phrase things so that you don't
need any uses of "(s)".
 
>> 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.

My point is that at present the template offers the user no such
background information.  How are they expected to make a decision?

(But now you mention it, if your problem is only with the install
stage, not the download-and-build stages, I'd just like to point out
that I'm not sure I would *want* this package to automatically install
the output .debs; I would prefer it to tell me where they are, so I
can throw the main package in my local repository and the -dev package
in the trash.)

>> 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...

Oh well, let's cut things short by agreeing that we can't reduce the
number of templates the way I was hoping.

>> 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.

Square brackets are meaningless line noise.  If you can tell me what
you're hoping to accomplish with them, I can try to find a solution that
actually conveys that.  Is it maybe intended as Python list syntax?  If
so, no, you don't get to do that; it's supposed to be self-evidently
comprehensible to English-speakers.
 
>> 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.

We *may* do all kinds of things.  But if this doesn't actually apply in
the case of libdvd-pkg, it's not a reason for making the templates for
libdvd-pkg harder to understand.
 
>> 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?

You think the end users who chose to install this package because you
advertised it to them as providing a way of watching DVDs are going to
want to build and install -dev packages?  That strikes me as
implausible.
 
>> 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.

That sounds like the kind of information that would make it much easier
to make a good decision.
 
>> 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.

But that means we're reviewing the wrong thing.  You've made it
pointless for us to try to fix the flaws in the debconf templates of
individual packages - we need to fix the master copies, wherever
you're keeping those.
 
>> 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.

Oh well, you're answering perfectly promptly this time round, so
thanks.
 
>> 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.

This is a particularly annoying sort of debconf note, since it's going
to come across as trying to nag me into enabling the hook.
 
>> (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.

Well, does the dpkg lock problem crop up this time or could the
debconf note make itself useful (and no longer a note) by actually
offering to do a one-off download/build/install?
 
>> 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.

No, sorry, that's not what I mean.  Look at it again:
#   Please remember to run "sudo dpkg-reconfigure ${PKGI}" to build and
#   install guest package(s) or consider installing the APT post-invoke
#   hook.
I'm being asked to either do "A" or "B".  "A" involves running 
dpkg-reconfigure; but if I want to do "B" then I *also* need to run
dpkg-reconfigure, don't I?  So that's not exactly a choice!
 
>> 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. 

Yes, we've recently seen a definitely worse approach - your actual
software looks good, I'm just nitpicking at your choice of terminology
in the documentation.  The "host/guest" distinction makes it sound as if
you're talking about a virtual machine.

>> 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...

Or, as I say, put them in ~/var/www/debian/.  But while *we* might want
to do this, as far as I can see libdvd-pkg always does the full
download/build/install process, so it's odd that it keeps omitting one
of those three stages from the list.
 
>> 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.

That's what you seemed to be implying with "automatic upgrades of guest
package(s) on host package upgrade".  If it's not what you meant to
imply, you'll have to explain it more clearly.

> 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.

I took this text from "Template: fheroes2-pkg/post-invoke_hook-install",
but we could certainly drop details like that.

>>> - 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.

If you weren't prepared to allow us to review the templates and
package description, it would have helped if you had said so when we
asked.  (And sorry, but I'm not a developer.  I won't see commits unless
you can give me URLs I can browse to.)

>> 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.

I'm not sure you even need to do that.  Your package is aimed at users
who are *starting* by thinking "right, I've got a media player and a
DVD, is there some other thing I need?" - you don't have to include
adverts for the concept of watching DVDs on media players, you just need
to tell them what problem it solves.  Except that apparently telling
them this is illegal?!

>> 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.

It's legal to provide this software, but it *isn't* legal to explain
what CSS is?  I can understand that we don't want to say "this package
is a tool for pirating DVDs by illegally bypassing CSS encryption", but
I really think we could get a whole lot closer to mentioning the point
of the exercise.  For a start, with a minor tweak:

        Some features of the DVD-Video format use the Content Scramble
        System (CSS). Software to bypass this encryption cannot be
        distributed via the Debian repositories.

That's just a fact about a well-known publicly specified data format
followed by a fact about how completely law-abiding Debian is.  Could we
not put these undisputed innocent facts in the 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.

No, marmosets.  Lovely cute fluffy little baby marmosets that don't
make me want to strangle anybody...  sorry, I ought to be providing an
updated attempt at a patch, but instead I'm going to go for a walk.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package