Re: Bug#891188: blends-dev: created d/control recommends packages not in main
Hi Andreas
(completely moving to d/blends, since this is not bug related)
On 16.03.2018 14:17, Andreas Tille wrote:
> On Fri, Mar 16, 2018 at 01:51:25PM +0100, Ole Streicher wrote:
>> In the moment, I would tend to rewrite blend-gen-control from scratch,
>> using Python 3 and the standard Debian Python packages (debian.deb822,
>> apt) in a modular fashion. This would make the script much more
>> maintainable (given the knowledge of Python is a bit better than Perl),
>> and could also lead to create a "debian.blends" Python package that
>> could be re-used for the Web pages.
>
> 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.
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.
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?
> 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.
> 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?
> 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).
Best regards
Ole
Reply to: