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

[Dmitry Smirnov]

On Wednesday 12 August 2015 17:00:43 Justin B Rye wrote:
> 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!

I'm not happy about it too but unfortunately there are some conditions for 
this package to exist in the archive.


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

I like the use of word "software" but I do not like word "output" in this 
context. I respectfully disagree that it is "unfriendly" to try sharing 
common parts between packages of similar design (but not necessary similar 
purpose). It is an attempt to deduplicate the maintenance (and translators) 
effort -- it have nothing to do with users noticing similarity.


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

Would it be any less confusing if we always use plural form but sometimes 
actually mention only one package in square brackets?


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

Perhaps there is a room for improvements but I doubt such long explanations 
regarding design of the package can be expected to be given in debconf 
dialogs... I believe that just enough information to make decision is already 
provided, together with recommended defaults.


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

Sorry about that.


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

I do not see brackets as "meaningless line noise". In theory we could present 
list of packages as bulleted list but I prefer comma-separated list inside 
brackets for greater visibility.


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

It was not intended to be Python list syntax. I doubt English-speaking users 
would be so confused by list of packages in brackets. Do you really think 
brackets make it hard(er) to understand what's going on?


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

I insist that in general case debconf templates can't/shouldn't know how many 
binary guest packages will be produced.



> 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 doesn't matter. -dev package is in Provides field so it can be pulled 
despite of package description. The latter is targeted for end user rather 
than developer but guest software is installed as completely as possible.
Besides -dev package is lightweight and there is no harm to have in 
installed.


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

True. However I still don't know how to articulate it any better than I 
already did...


> >> 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 are reviewing the right 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.

There are no master copies. I diff and merge messages manually between two 
packages for now. When stabilised, I might create a master repo to sync from.


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

It gives you the choice -- either to allow automatic upgrades (as recommended 
mode of operation) or be notified when manual upgrade is necessary.
"Annoying sort of debconf note" was introduced on demand by ftp-masters as 
condition for entering archive. Package can do what it is intended to do only 
when hook is enabled. If giving user more freedom in configuring the way 
package operates then so be it...


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

I need to think about that. At the moment it makes sense to let user know 
before making packages on "dpkg-reconfigure" invocation. I do not feel that 
this needs to be changed now.


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

If we're talking about first install then the it is a choice regarding future 
upgrades of the package. As I've mentioned, "A" suggests to run dpkg-
reconfigure to build guest packages without delay. "first-install" dialog 
specifically mention building/installation "for the first time".


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

Thank you. I reckon "host" and "guest" are such a broad terms that they 
hardly imply virtualisation. Nevertheless I reckon I've used "host/guest" for 
the lack of better terms...


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

README.Debian already mention where generated packages can be found (e.g. 
"/usr/src/libdvd-pkg").


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

I'm not sure I quite follow you here... Which operation is omitted?



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

No we don't need to explain it more clearly in debconf dialogs. README.source 
explains some design concepts. As you may have already noticed host package 
version incorporates guest package version (including debian revision number) 
as "upstream" version. Host package have its own debian revision number which 
can change without triggering guest source package re-build. Only change to 
"upstream" part of the version triggers re-build. Certainly there is no need 
to explain that in full details anywhere but in README.source.


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

Agreed. Besides if I recall correctly I've never merged such technical 
details into "fheroes2-pkg/post-invoke_hook-install"...


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

I have no objections against review and I'm not against it. Though I had no 
idea that I would have to defend technical design of the package. ;)

It did not occur to me that I had to tell about how sensitive package 
description is but I'm quite all right with improving it even if there are 
limits to acceptable changes. Maybe we can focus on improving debconf dialogs 
first?


> (And sorry, but I'm not a developer.  I won't see commits unless
> you can give me URLs I can browse to.)

Sorry I thought package metadata or link from PTS page makes it easy enough 
to find repository:

    https://anonscm.debian.org/cgit/pkg-multimedia/libdvd-pkg.git


> >> 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?!

Yeah, unfortunately package description can't reproduce any parts of 
libdvdcss description...

On second thought it could be useful to know which players can take advantage 
of installed libdvdcss library. For that matter it makes perfect sense to 
mention particular players.


> It's legal to provide this software, but it *isn't* legal to explain
> what CSS is?

Yes. However even if we can't elaborate what it does at least we say what 
software is going to be installed so users can read about it elsewhere...


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

I've been through this countless times. No, CSS can't be mentioned nor what 
Debian can (or can not) distribute.


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

It makes me feel quite uncomfortable but it seems that we can't/shouldn't do 
it...


> I ought to be providing an
> updated attempt at a patch, but instead I'm going to go for a walk.

I need a walk too as we got ourselves into rather tiresome discussion... :)

-- 
Best wishes,
 Dmitry Smirnov.

---

You have enemies? Good. That means you've stood up for something,
sometime in your life.
        -- Victor Hugo, "Villemain", 1845
           (often misattributed to Winston Churchill)
-------------- 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/20150813/742171ab/attachment-0001.sig>