Re: Bug#891188: blends-dev: created d/control recommends packages not in main
On Fri, Mar 16, 2018 at 03:07:46PM +0100, Ole Streicher wrote:
> > I can only repeat: Blends-dev *was* rewritten and creates correct
> > results:
> > https://salsa.debian.org/blends-team/blends-gsoc
> I was not aware that the rewrite was done in Python.
I made probably even to less noise about it - despite I somehow felt to
report about it every three monthes.
> Anyway: That one is not much better. It is in Python, OK, but it is not
> more modular, and it implements everything by itself instead of re-using
> standard packages (namely debian.deb822 and apt). What I want to have is
> something like
> from debian.blends import Task
> t = Task('tasks/education')
> and t then "looks like" (duck-typing) the apt (versionized) package that
> one would get with
> import apt
> c = apt.Cache()
> t = c['astro-education'].version
> so that "t.recommends" gets apt.package.Dependency-like dependencies etc.
> In principle, one could do the same by generating the Task from UDD.
> But, I don't see why calling UDD instead of using the local tasks
> definition has an advantage for writing d/control. UDD makes it
> difficult for non-Debian blends/distributions: how f.e. would Mint Linux
> get it? Or how would a blend that is not in the UDD get the information
> about its metadata?
The point is: UDD has the information about all *architectures* and you
would need to parse a full matrix of Packages files to reach the same
effect. We have all information fully gathered in UDD.
> > I repeat again: This creates *architecture* dependent metapackages (I
> > explained here why only this makes sense).
> Could you point me to your explanation please? I missed it.
Since some time I have the impression that site searches on Debian
lists do not work as before. I'm using notmuch on my local mail
archive to uncover the links (in reverse time order):
3. just a mention that rewrite should be done not worth reading
In 4. its a direct reply to a mail of yours (you in CC ;-) )
In short: Our metapackages claim to be Architecture: all but they are
only granted to work on amd64 and are probably mostly all broken on any
> > I'm all for switching to
> > Python3 but a complete rewrite should not be necessary. There are some
> > glithes in the code (for instance line breaking in the auto generated
> > part of d/changelog) and it definitely needs testing.
> I would re-use parts of it, but I am a bit resistant of "just finishing"
> it. And the word "changelog" does not appear in its blends-gen-control?
Feel free to try a make dist. If you do not have a local UDD clone I'd
volunteer to redirect the code to the public mirror. It generates
automatic changelog entries - feel free to check debian/changelog of
debian-med and watch out for "start of automatic changelog entry".
> > I *really* appreciate your effort but may be 80% of the work is just
> > done and you try blends-gsoc first. As we all know the last 20% is
> > the harder part - but I urgently vote for using UDD as base for
> > anything we use. May me using the public UDD mirror can help to not
> > force everybody who wants to run blends-dev having a local clone.
> I will have a deeper look into the package. However, for package
> creation UDD looks to me the wrong tool (see above).
I see no sensible way around UDD - but feel free to prove me wrong. I'm
open to anything that will enable us to get rid of the old Perl code and
creates architecture dependant metapackages.