Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Hi all,

Mike Gabriel  writes:
> Nonetheless, the current status of blends-dev is:
>
>  1. it now fully suppors two modes "nodepends=true" (aka -D) and
> "nodepends=false (aka without -D)
>  2. the "nodepends=true mode is the default

I still think it would be better to depend on a tag within the tasks
file.

There is one more question now coming up: in the blends tasks pages, we
currently have two sections covering files in main:

* "Official Debian packages with high relevance" (Depends: and
  Recommends: fields in the tasks pages)
* "Official Debian packages with lower relevance" (Suggests: fields in
  the tasks pages)

After the change, we will have an additional section with the packages
that essential (the new "Depends:" section).

First question: how should that be named?
Second question: how do we handle the transition to not have the
packages silently in wrong sections?

Best regards

Ole

Re: change proposal for handling of Depends: field in task files

[Mike Gabriel]

Hi Andreas,

On  Sa 12 Aug 2017 17:28:50 CEST, Andreas Tille wrote:


[...]



I've did a s/^Depends:/Recommends/ debian-med:tasks/* and the code works
nicely.  So I decided to upload the new blends-dev.


Thanks for uploading. Can you also push your changelog changes to the  
Git repo? Thanks!



Thanks a lot for working on this.  Obviously I turned a bit demotivated
in adding new features to what worked for me perfectly.  Fresh blood
really helps to add new features.

Many thanks, your contribution is very well received


You are welcome :-)

Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp1YjLXCdPJP.pgp
Description: Digitale PGP-Signatur

Re: change proposal for handling of Depends: field in task files

[Andreas Tille]

Hi Mike,

On Sat, Aug 12, 2017 at 04:40:38AM +, Mike Gabriel wrote:
> > In a second round we could later change the behaviour of Depends.  I
> > agree that technically that's a weak solution but should work if
> > somebody intends to reproduce older packages since we would fail to
> > reproduce older packages from older Git commits.  However, I do not
> > consider this a strong argument over burning developer time with
> > implementing and testing a more complex versioning + format system.
> 
> I have now pushed several commits for debian-blends. Unfortunately, they
> stack on each other and earlier code gets reworked by later commits. Never
> push before you are done with full testing... Well.
> 
> Nonetheless, the current status of blends-dev is:
> 
>  1. it now fully suppors two modes "nodepends=true" (aka -D) and
> "nodepends=false (aka without -D)
>  2. the "nodepends=true mode is the default
> 
>   => this means, all blends packages can stay as they are!
>   => no need to depromote packages in task files from Depends: to Recommends:
> 
>  3. I fully reworked the control file generation for nodepends=false
> 
>   => this closes #825172, make sure to include that in debian/changelog
> 
>  4. the nodepends=false mode can be enabled in the blends package's Makefile
> by setting GENCONTROL_DEPENDS = true
> 
>   => see  
> https://anonscm.debian.org/cgit/debian-edu/debian-edu.git/commit/?id=621a2498bdc6127cc57c4ecfcad158300d9dfa0f
>  for an example
> 
>  5. if nodepends=false (i.e. Depends become Depends), then also packages
> are checked now for availability in unstable and depromoted to Suggests:
> if missing
> 
> Hope this works well for everyone, feedback welcome!

I've did a s/^Depends:/Recommends/ debian-med:tasks/* and the code works
nicely.  So I decided to upload the new blends-dev.

Thanks a lot for working on this.  Obviously I turned a bit demotivated
in adding new features to what worked for me perfectly.  Fresh blood
really helps to add new features.

Many thanks, your contribution is very well received

  Andreas.

-- 
http://fam-tille.de

Re: change proposal for handling of Depends: field in task files

[Mike Gabriel]

HI Andreas, hi all,

On  Sa 05 Aug 2017 13:25:48 CEST, Andreas Tille wrote:


2. We create bugs for all known build-dependencies of blends-dev to
2.1 'sed s/^Depends:/Recommends:/ -i tasks/*`
2.2 insert a "Format: https://blends.d.o/format; as first line to
indicate that the new format is used

3. Once all switched (should be not that difficult, due to the
 straightforward change), we upload a new version of blends-dev that
 checks the format id and
 a) either exits with error if it is not there or a wrong one
 b) prints a depretation warning and proceeds with the old style in that
case
 Because of the trivial change, I would prefer a).


I admit for the sake of simplicity (and the fact that we have only a
few Blends we could deal with easily) we could simply fix blends-dev
to accept Recommends.  After this we could inform those few Blends
maintainers (I'll be responsible for med, science and junior), I guess
Debian GIS and Debian Games are also happy about the change, no idea
about Debian Multimedia and how/whether it is maintained at all,
Debian Accessibilities only uses web sentinel (no metapackages - I
would do the change here as well) and finally EzGo which is kind of
a riddle to me.

In a second round we could later change the behaviour of Depends.  I
agree that technically that's a weak solution but should work if
somebody intends to reproduce older packages since we would fail to
reproduce older packages from older Git commits.  However, I do not
consider this a strong argument over burning developer time with
implementing and testing a more complex versioning + format system.


I have now pushed several commits for debian-blends. Unfortunately,  
they stack on each other and earlier code gets reworked by later  
commits. Never push before you are done with full testing... Well.


Nonetheless, the current status of blends-dev is:

 1. it now fully suppors two modes "nodepends=true" (aka -D) and
"nodepends=false (aka without -D)
 2. the "nodepends=true mode is the default

  => this means, all blends packages can stay as they are!
  => no need to depromote packages in task files from Depends: to Recommends:

 3. I fully reworked the control file generation for nodepends=false

  => this closes #825172, make sure to include that in debian/changelog

 4. the nodepends=false mode can be enabled in the blends package's Makefile
by setting GENCONTROL_DEPENDS = true

  => see   
https://anonscm.debian.org/cgit/debian-edu/debian-edu.git/commit/?id=621a2498bdc6127cc57c4ecfcad158300d9dfa0f

 for an example

 5. if nodepends=false (i.e. Depends become Depends), then also packages
are checked now for availability in unstable and depromoted to  
Suggests: if missing


Hope this works well for everyone, feedback welcome!

Greets,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpf4cndgR61O.pgp
Description: Digitale PGP-Signatur

Re: change proposal for handling of Depends: field in task files

[Andreas Tille]

On Thu, Aug 10, 2017 at 02:33:49PM +0200, Petter Reinholdtsen wrote:
> 
> > This additional line even works if the URL is not valid yet -- but gives
> > us some additional pressure to create an up-do-date format description
> > (which is IMO not the worst thing).
> 
> I guess what Andreas really is wondering about is who is going to do the
> work, not how hard it would be. :) I agree that it sound fairly easy to
> do, but it is unlikely that I will find time to do it myself any time
> soon. :(

Thanks for reading my mind.  I can perfectly add the Recommends and by
doing so let my local debian-med clone work again before pushing it.
I just want to avoid a race condition.  I will not do it before tomorrow
11:00 Montreal local time but afterwards I'll work on a new version
accepting Recommends.
 
> > So, what about
> >
> > Format: https://blends.debian.org/doc/0.7/tasksformat.html
> >
> > (blends-doc has currently version 0.6.98; 0.7 would be the logical
> > next step)
> 
> I believe it is a good idea to not link the format version and the
> package version, and would suggest to either start with a version number
> 0 or 1 for the format.  Locking the two together would give us an
> incetive to not change the version number of the package without making
> large changes to the task format, which seem like a bad idea to me.
> 
> Also, I believe the version number should be at the end of the URL, to
> make it obvious that it is possible to get a list all versions by
> removing the last part.

+1
 
> What about something like
> 'Format: https://blends.debian.org/doc/tasksformat/0/' instead?  Or
> perhaps version '0 is the old moving target, and version '1' is the
> first one we document?

I'd vote for using version '1' for the first we document.

Regarding the package version.  The idea to stick to 0.6.x was that

ssh://git.debian.org/git/blends/blends-gsoc.git

is starting with 0.7.  Since this never went into production (but
should) there is no point in reserving the 0.7 minor version.  The
Python rewrite which uses UDD and is *way* better since the old Perl
stuff should be somehow pushed for buster.  It simply needs more
testing.  I wonder who is aware of this - may be I should make some
summary.  The main point is that we get architecture dependant
metapackages.  Strictly speaking all our non amd64 metapackages are
wrong since we have usually not all dependencies available on other
architectures.  That's finally the reason why my motivation to keep
on working on the old blends-dev package is very limited but I never
found the time to push the rewritten code into production.  Everybody
is welcome to check it out.  (If I remember correctly it also
respects Recommends ...)

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: change proposal for handling of Depends: field in task files

[Petter Reinholdtsen]

[Ole Streicher]
> Sorry, I don't see the big problem here: The first step is anyway just
> to extend blends-dev to accept "Recommends" aside of "Depends", which
> should be simply enough. Then, the only disagreement is that I propose
> to have a required Format: line in the tasks header; this should be
> trivial enough as well (as long as we agree on the URL itself).
>
> This additional line even works if the URL is not valid yet -- but gives
> us some additional pressure to create an up-do-date format description
> (which is IMO not the worst thing).

I guess what Andreas really is wondering about is who is going to do the
work, not how hard it would be. :) I agree that it sound fairly easy to
do, but it is unlikely that I will find time to do it myself any time
soon. :(

> So, what about
>
> Format: https://blends.debian.org/doc/0.7/tasksformat.html
>
> (blends-doc has currently version 0.6.98; 0.7 would be the logical
> next step)

I believe it is a good idea to not link the format version and the
package version, and would suggest to either start with a version number
0 or 1 for the format.  Locking the two together would give us an
incetive to not change the version number of the package without making
large changes to the task format, which seem like a bad idea to me.

Also, I believe the version number should be at the end of the URL, to
make it obvious that it is possible to get a list all versions by
removing the last part.

What about something like
'Format: https://blends.debian.org/doc/tasksformat/0/' instead?  Or
perhaps version '0 is the old moving target, and version '1' is the
first one we document?

-- 
Happy hacking
Petter Reinholdtsen

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Andreas Tille  writes:
> On Tue, Aug 08, 2017 at 09:04:56PM +0200, Ole Streicher wrote:
>> Mike Gabriel  writes:
>> > Is anyone here maintaining blend packages that have not been uploaded
>> > to Debian? If so, please speak up.
>> 
>> My point was here: If we introduce a format identifier (like an URL), we
>> can very simply test for it and exit with error if it is the wrong one.
>> 
>> The required changes in the tasks are trivial, so there would be no need
>> to support more than the "new" format. Anyone who did not get the bang
>> can just change it then.
>
> I wonder if all this format discussion might keep us away to continue
> with the simple solution to just do it and break things that are
> outside.  IMHO it should not stop our progress if outside people are
> using things that are intended for inside.  I would be very happy if
> some of the perl programmers would do that supposedly simple change and
> we could continue with interesting things.

Sorry, I don't see the big problem here: The first step is anyway just
to extend blends-dev to accept "Recommends" aside of "Depends", which
should be simply enough. Then, the only disagreement is that I propose
to have a required Format: line in the tasks header; this should be
trivial enough as well (as long as we agree on the URL itself).

This additional line even works if the URL is not valid yet -- but gives
us some additional pressure to create an up-do-date format description
(which is IMO not the worst thing).

So, what about

Format: https://blends.debian.org/doc/0.7/tasksformat.html

(blends-doc has currently version 0.6.98; 0.7 would be the logical next
step)

Best

Ole

Re: change proposal for handling of Depends: field in task files

[Andreas Tille]

Hi,

On Tue, Aug 08, 2017 at 09:04:56PM +0200, Ole Streicher wrote:
> Mike Gabriel  writes:
> > Is anyone here maintaining blend packages that have not been uploaded
> > to Debian? If so, please speak up.
> 
> My point was here: If we introduce a format identifier (like an URL), we
> can very simply test for it and exit with error if it is the wrong one.
> 
> The required changes in the tasks are trivial, so there would be no need
> to support more than the "new" format. Anyone who did not get the bang
> can just change it then.

I wonder if all this format discussion might keep us away to continue
with the simple solution to just do it and break things that are
outside.  IMHO it should not stop our progress if outside people are
using things that are intended for inside.  I would be very happy if
some of the perl programmers would do that supposedly simple change and
we could continue with interesting things.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Mike Gabriel  writes:
> Is anyone here maintaining blend packages that have not been uploaded
> to Debian? If so, please speak up.

My point was here: If we introduce a format identifier (like an URL), we
can very simply test for it and exit with error if it is the wrong one.

The required changes in the tasks are trivial, so there would be no need
to support more than the "new" format. Anyone who did not get the bang
can just change it then.

Best regards

Ole

Re: change proposal for handling of Depends: field in task files

[Andreas Tille]

Hi Mike,

On Mon, Aug 07, 2017 at 09:40:07PM +, Mike Gabriel wrote:
> > What about doing it the other way around, and change behaviour of
> > blends-dev for the tasks with a format line and leave the old behaviour
> 
> The issue about the tasks files is that they look like debian/control, but
> behave entirely differently.

I'm all for making tasks files RFC822 compatible.
 
> > as it is for those without it?  This will be more like debhelper
> > compatiblity levels, and we can handle many different behaviours without
> > breaking existing packages.
> 
> We break and immediately fix existing packages. I have already started
> downgrading various packages in debian-edu task files from Depends: to
> Recommends:.
> 
> For the other blends, afaict Andreas is open to downgrading all Depends: to
> Recommends:, too.

Yes.  Its done in my local Git repository.

> Problematic are blend packages that exist on the planet
> and are not in Debian.

Sorry, that's per definition no problem for us.  Blends is an internal
thing in Debian and was never announced as a tool for external use.
 
> Is anyone here maintaining blend packages that have not been uploaded to
> Debian? If so, please speak up.

... or just adapt.
 
> > This way the debian-edu package could set 'Format: .../format/2' or
> > similar to get the new behaviour, and the others might migrate at their
> > own leisure.
> 
> If we want to support blend packages outside of Debian, we probably have to
> had something like that to the header.

I repeat I'd love to make things simple.  If people run into problems
since they stay outside I do not care very much ... as long as the fix
is as simple as a sed one liner.

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: change proposal for handling of Depends: field in task files

[Mike Gabriel]

Hi Petter,

On  Sa 05 Aug 2017 11:52:57 CEST, Petter Reinholdtsen wrote:


[Ole Streicher]

The number of blends is countable: I personally like the idea to first
replace all "Depends" with "Recommends" in all tasks files, and then
change the behaviour of the "blends-dev" package.

We should also introduce a format identifier to make future changes
easier; so my proposal would be:

1. We write a (maybe preliminary) format description and publish it
under a well-defined URL

2. We create bugs for all known build-dependencies of blends-dev to
2.1 'sed s/^Depends:/Recommends:/ -i tasks/*`
2.2 insert a "Format: https://blends.d.o/format; as first line to
indicate that the new format is used

3. Once all switched (should be not that difficult, due to the
 straightforward change), we upload a new version of blends-dev that
 checks the format id and
 a) either exits with error if it is not there or a wrong one
 b) prints a depretation warning and proceeds with the old style in that
case
 Because of the trivial change, I would prefer a).


What about doing it the other way around, and change behaviour of
blends-dev for the tasks with a format line and leave the old behaviour


The issue about the tasks files is that they look like debian/control,  
but behave entirely differently.




as it is for those without it?  This will be more like debhelper
compatiblity levels, and we can handle many different behaviours without
breaking existing packages.


We break and immediately fix existing packages. I have already started  
downgrading various packages in debian-edu task files from Depends: to  
Recommends:.


For the other blends, afaict Andreas is open to downgrading all  
Depends: to Recommends:, too. Problematic are blend packages that  
exist on the planet and are not in Debian.


Is anyone here maintaining blend packages that have not been uploaded  
to Debian? If so, please speak up.



This way the debian-edu package could set 'Format: .../format/2' or
similar to get the new behaviour, and the others might migrate at their
own leisure.


If we want to support blend packages outside of Debian, we probably  
have to had something like that to the header.


Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpXvyRJH3jjR.pgp
Description: Digitale PGP-Signatur

Re: change proposal for handling of Depends: field in task files

[Andreas Tille]

Hi Ross,

On Sat, Aug 05, 2017 at 03:26:57PM +0200, Ross Gammon wrote:
> > Non maintained blends cout get an NMU, and also then the bug report
> > helps documenting the process.
> >
> I am looking after Debian Multimedia with help from Felipe & IOhannes
> (mainly) these days. We created some new tasks just before the Stretch
> freeze, so the next upload needs to pass through NEW. Hopefully my DD
> account is set up soon, and I can do it without needing sponsorship!

Fine.  Thanks for confirming.
 
> I will at least s/Depends/Recommends as soon as I see the bug, and ask
> one of you to upload if I am still not a DD.
 
I think I remember you are at least DM.  So we could grant you upload
permissions, right?  If not, sponsoring is granted at very short notice.

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: change proposal for handling of Depends: field in task files

[Andreas Tille]

Hi Ole,

On Sat, Aug 05, 2017 at 02:04:08PM +0200, Ole Streicher wrote:
> I my feeling right that you basically propose the same as I?

The idea is the same - I'd like to go simpler without the technical
format definition stuff.
 
> So, we should do a 0th step and fix blends-dev to accept Recommends: as
> well (and translates it to Recommends: at package dependency level)

Yes.
 
> > I think the first change in blends-dev should be to accept Recommends.
> 
> Ack. Should be trivial to fix.

I'm pretty sure that it would be easy enough that even I could do it but
I'd be more than happy if some Perl programmer would take over.
 
> > I admit for the sake of simplicity (and the fact that we have only a
> > few Blends we could deal with easily) we could simply fix blends-dev
> > to accept Recommends.
> 
> Ack. This is the first step and seems not nontroversial at all.

Yes.  It could be implemented right now.
 
> > After this we could inform those few Blends maintainers (I'll be
> > responsible for med, science and junior)
> 
> Ack. The usual way to "inform other blends" (which means: ask them to
> change something in their blends packages) is a bug report, which would
> also help us to track the progress.

Yes, bug reports should be fine.  I'll convert the Blends where I'm
responsible before to use them as test case.
 
> > I guess Debian GIS and Debian Games are also happy about the change,
> > no idea about Debian Multimedia and how/whether it is maintained at
> > all, Debian Accessibilities only uses web sentinel (no metapackages -
> > I would do the change here as well) and finally EzGo which is kind of
> > a riddle to me.
> 
> Non maintained blends cout get an NMU, and also then the bug report
> helps documenting the process.

Definitely.
 
> > In a second round we could later change the behaviour of Depends.
> 
> Ack. And to make sure that no older blends metapackage slips through
> (maybe local, or in a derivative), we should mark the new format
> somehow -- which brings the "Format:" header line into the game.
> 
> Any old-style blends metapackage would then fail to build (and could
> again easily be fixed).

As I tried to express I'm relaxed about the Format header since to my
personal opinion the effort-benefit releation is not very positive.
I'm perfectly fine if somebody wants to implements and will test it.
 
> > I agree that technically that's a weak solution but should work if
> > somebody intends to reproduce older packages since we would fail to
> > reproduce older packages from older Git commits.  However, I do not
> > consider this a strong argument over burning developer time with
> > implementing and testing a more complex versioning + format system.
> 
> I do not see a use case for this. Even when backported, one could still
> generate the source package on a current system. And if we provide a
> simple (sed) script that does s/^Depends:/Recommends:/ (and adds the
> format line in the begining), one could manually apply this before
> further processing with blends-dev.

As I said that's perfectly fine for me.  May be I failed to express
correctly what I meant:  The only flaw I would see in skipping the
explicite mentioning of Format at all would be that you can not recreate
old metapackages.  Since I fully agree that there is no real use case
for this I would take the "risk" and do not deal with the Format hassle
(for the current problem).

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Hi Andreas,

I my feeling right that you basically propose the same as I?

Andreas Tille  writes:
> I'm all for it.  I just did `sed -i 's/^Depends/Recommends/' tasks/*` in
> Debian Med packages but while I assumed that this would work with
> blends-dev unfortunately it does not.  I need to check this later since
> I'm busy with other stuff.  I think the web sentinel threats Depends and
> Recommends equally so the replacement should not harm.

So, we should do a 0th step and fix blends-dev to accept Recommends: as
well (and translates it to Recommends: at package dependency level)

>> and then change the behaviour of the "blends-dev" package.
>
> I think the first change in blends-dev should be to accept Recommends.

Ack. Should be trivial to fix.

> I admit for the sake of simplicity (and the fact that we have only a
> few Blends we could deal with easily) we could simply fix blends-dev
> to accept Recommends.

Ack. This is the first step and seems not nontroversial at all.

> After this we could inform those few Blends maintainers (I'll be
> responsible for med, science and junior)

Ack. The usual way to "inform other blends" (which means: ask them to
change something in their blends packages) is a bug report, which would
also help us to track the progress.

> I guess Debian GIS and Debian Games are also happy about the change,
> no idea about Debian Multimedia and how/whether it is maintained at
> all, Debian Accessibilities only uses web sentinel (no metapackages -
> I would do the change here as well) and finally EzGo which is kind of
> a riddle to me.

Non maintained blends cout get an NMU, and also then the bug report
helps documenting the process.

> In a second round we could later change the behaviour of Depends.

Ack. And to make sure that no older blends metapackage slips through
(maybe local, or in a derivative), we should mark the new format
somehow -- which brings the "Format:" header line into the game.

Any old-style blends metapackage would then fail to build (and could
again easily be fixed).

> I agree that technically that's a weak solution but should work if
> somebody intends to reproduce older packages since we would fail to
> reproduce older packages from older Git commits.  However, I do not
> consider this a strong argument over burning developer time with
> implementing and testing a more complex versioning + format system.

I do not see a use case for this. Even when backported, one could still
generate the source package on a current system. And if we provide a
simple (sed) script that does s/^Depends:/Recommends:/ (and adds the
format line in the begining), one could manually apply this before
further processing with blends-dev.

Best regards

Ole

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Petter Reinholdtsen  writes:
> We started by using depends.  This proved a disaster, as the meta
> packages would be close to impossible to keep in testing.  It would be
> thrown out or blocked from entering testing whenever any of the more
> than 1000 packages we want had a RC problem.
>
> After struggling with this for a few years, we decided to use recommends
> instead.

The problem here is IMO that the task still says "Depends", which is
translated into "Recommends": this is just not intuitive. And it
requires that a task that has a strong real "Depends" needs to do some
workarounds.

The number of blends is countable: I personally like the idea to first
replace all "Depends" with "Recommends" in all tasks files, and then
change the behaviour of the "blends-dev" package.

We should also introduce a format identifier to make future changes
easier; so my proposal would be:

1. We write a (maybe preliminary) format description and publish it
under a well-defined URL

2. We create bugs for all known build-dependencies of blends-dev to
2.1 'sed s/^Depends:/Recommends:/ -i tasks/*`
2.2 insert a "Format: https://blends.d.o/format; as first line to
indicate that the new format is used

3. Once all switched (should be not that difficult, due to the
 straightforward change), we upload a new version of blends-dev that
 checks the format id and
 a) either exits with error if it is not there or a wrong one
 b) prints a depretation warning and proceeds with the old style in that
case
 Because of the trivial change, I would prefer a).

Best regards

Ole