[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: