Re: Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Ole,
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[0]
>
> so that "t.recommends" gets apt.package.Dependency-like dependencies etc.
Fair enough.
> 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):
1. https://lists.debian.org/debian-blends/2018/01/msg00008.html
2. https://lists.debian.org/debian-blends/2017/08/msg00020.html
3. just a mention that rewrite should be done not worth reading
https://lists.debian.org/debian-blends/2016/10/msg00003.html
4. https://lists.debian.org/debian-blends/2016/05/msg00049.html
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
other architecture.
> > 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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: