Re: change proposal for handling of Depends: field in task files
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
Reply to: