[Pkg-javascript-devel] parallel installation

[Hubert Chathi]

On Tue, 19 Sep 2017 22:27:34 +0200, Paul Gevers <elbrus at debian.org> said:

> Hi Hubert, Thanks for writing this down.

> On 19-09-17 17:58, Hubert Chathi wrote:
>> https://wiki.debian.org/HubertChathi/JavaScriptPolicy
>> 
>> Please let me know what you all think of it, and suggest
>> improvements/fixes/etc.

> I was wondering how you envision the following: "The source package
> name may also include the APIVERSION in its name." I mean, if the
> binary package should contain it, and there are multiple versions,
> shouldn't the source package also contain it? Or is this related to
> the last paragraph of that chapter?

In general, I went for more permissive language rather than mandating
what *has* do be done, partly in order to account for the status quo.
So you are right that if two source packages provide different
APIVERSIONs, then they need to have different names.  But what I didn't
want to do was to automatically make every JavaScript package that's
currently in Debian non-compliant, which is what would happen if I we
made it a "MUST".

What I was thinking of was, to pick a random example, libjs-jquery is
currently built from the jquery source package.  If a new jQuery comes
out which breaks the API, then the new source package would be named,
say jquery4 or jquery3.3 or whatever, while the old source package would
remain plain "jquery".

I would be fine changing that to a "should", if other people would
prefer that.

> Also, I think we want some more words when the package with APIVERSION
> is "updated" with a newer version. I.e. I think it shouldn't be
> updated when you still want to provide the old APIVERSION, but instead
> there should be a new package. Or are you envisioning to provide
> multiple APIVERSIONs from the same source (I would recommend against
> that, although since the latest uscan version less so).

I'm not sure what kind of situation you're referring to.  Maybe you can
explain a bit more?

If a library still provides an old APIVERSION, then it can still keep
the same APIVERSION.  Unless you're talking about the situation where a
library provides an old APIVERSION but it's deprecated and will be
removed in a future version.  So, say, foo1 uses the old API, foo2 has
both the old API and the new API, and foo3 has just the new API.  In
that case, I guess foo2 could be packaged as libjs-foo2, with a
"Provides: libjs-foo1".  Would this solve the situation you're thinking
of?

> Last time we discussed a target for how many APIVERSIONs are
> allowed. I don't remember quickly what came out of that discussion,
> but maybe having the discussion (or different opinions) reflected in
> the policy as point to consider may be appropriate.

I don't think there was a consensus on how many APIVERSIONS to allow, or
whether there should be any limit at all.  I could probably add in some
language saying something about trying to limit the number of versions
packaged to a "reasonable" number.

BTW, I seem to have omitted the "Exclude auto-generated files from
source" section entirely, which was not intentional.  So until I add
that back in, then pretend that it's at the bottom of my proposal.

I did remove the bit about the "source package name should be called
foo.js" on purpose, since it seems not many packages actually follow
that.  But I can re-add that if others think it should go back in.

-- 
Hubert Chathi <uhoreg at debian.org> -- https://www.uhoreg.ca/
Jabber: hubert at uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368