Re: Bug#786448: [RFR] templates://neurodebian/{neurodebian.templates}
Thanks for taking the time to double-check my efforts!
Yaroslav Halchenko wrote:
[...]
> BTW -- if easier, neurodebian package is available also from github
> (https://github.com/neurodebian/neurodebian/) so if you are working
> within git -- feel more than welcome to send a PR with the changes to
> be merged.
Sorry, no, I don't really understand Git.
> On Thu, 04 Jun 2015, Justin B Rye wrote:
>>> -_Description: Should NeuroDebian repository be enabled?
>>> +_Description: Enable the NeuroDebian packages repository?
>
>> Make that "package repository".
>
> wouldn't it collide with "NeuroDebian package" as if it is only about
> that package (or packages for that sake)?
A "NeuroDebian package repository" might mean "a repository for the
NeuroDebian package" *if* there was some reason to expect that single
package to have a repository of its own, but if that was what it
meant, it would be a mistake to capitalise it as "NeuroDebian" - the
individual package is called "neurodebian".
There's a tricky point of English syntax here. In a stack of nouns
like "window manager bug tracker", we don't normally say "windows" or
"managers" or "bugs" even though there are presumably lots of them.
However, there are also plentiful exceptions.
Putting all that to one side, we could in fact get by with just
_Description: Enable the NeuroDebian repository?
since no other sort of repository is relevant.
>>> - NeuroDebian project provides a separate APT repository with backport
>>> - builds of most recent releases of maintained software, datasets and
>>> - some software not in Debian proper yet. Enabling this additional
>>> - repository will make those packages available on your base system.
>>> + The NeuroDebian project provides a separate APT repository with
>>> + the most recent releases of maintained software and datasets as
>>> + well as software that is not yet provided in Debian.
>
>> Are we avoiding the phrase "backport builds" on the basis that it's
>> developer jargon? The trouble is, backports aren't necessarily the
>> same thing as "the most recent releases". And does "maintained
>> software" mean "some software (which we're maintaining)" or "only the
>> software that's maintained"? And doesn't the category "software that
>> is not yet provided in Debian" also cover both the backports and
>> datasets?
>
> first to clarify: some software packages we are not directly
> maintaining ourselves (thus "we're maintaining" would be misleading) --
> some are maintained by upstream authors, some we simply re-build
> to provide backports from current testing.
I'm afraid that hasn't helped. Why do you specify that the project
provides "backport builds of [the] most recent releases of
*maintained* software" if it also provides software that you're only
backporting, and if that *doesn't* count as "maintaining" it?
Oh well - the word "maintained" doesn't occur in my draft, so maybe we
can just ignore this question.
> To address your comment about "the most recent", I would be ok
> rephrasing "the most recent releases" into "recent releases".
It's okay, I wasn't quibbling about that; I was saying that specifying
that they're backports provides extra information. In ten years time
the .deb in question won't be a "recent release", but it will still be
a "backport".
> I am ok to avoid "backports" (since we also have "standalone" and
> "sloppy" builds ;) )
Well, "standalone" builds are a different thing, but "sloppy" builds
(at least in the old "volatile-sloppy" sense) *are* backports, aren't
they? The only thing different about them was that they're backports
to release N of a package version newer than the one in release N+1.
>> Maybe we should just say:
>
>> The NeuroDebian project provides a separate APT repository with
>> software that is not available in Debian, including datasets and
>> backported new releases.
>
> This phrasing imho misleads a bit since majority of the software we
> provide from NeuroDebian IS available in Debian (we aim to upload to sid
> and NeuroDebian at the same time), just possibly of previous
> releases.
I'm not sure what you mean by "just possibly of previous releases".
Why would you bother keeping software in the NeuroDebian repos if the
exact same piece of software (with the same version number) is always
going to be present in Debian? Surely the point of the repository is
the software it contains that *isn't* available from elsewhere?
Maybe we're just interpreting "software" slightly differently?
Besides, a repository "with" package version 3.1 isn't necessarily a
repository *without* version 1.0.
And anyway:
>> I should hope by the time they're reading this users would already
>> know what NeuroDebian is anyway.
[...]
>>> Template: neurodebian/release
>>> Type: select
>>> -Choices: auto, ${releases}
>>> +__Choices: automatic, ${releases}
>>> +Choices-C: auto, ${releases}
>
>> Oh, one of these.
>
> any preference? ;)
I just mean "oh, this is one of those templates with a Choices-C
field". Though if I get the option, I'll pick "automatic", thanks!
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: