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

Re: New feature for 0.6.103



Andreas Tille <andreas@an3as.eu> writes:
> On Tue, Apr 10, 2018 at 11:30:07AM +0200, Ole Streicher wrote:
>> > $ git clone https://ole.ath.cx/blends/
>> > Klone nach 'blends' ...
>> > fatal: repository 'https://ole.ath.cx/blends/' not found
>> 
>> My wording was easy to misunderstand. I mean:
>> 
>> $ firefox https://ole.ath.cx/blends/
>> 
>> and then check what you read ;-)
>
> Ahhh- I admit I did this as well.  Please note that this page throws an
> error behind some proxy-firewall-whatever combination.  I needed to use
> my LTS-bound laptop to view the page.

They are just a static copy, so I don't know what could be wrong here.

>     When the header does not contain a line
>     Format: https://blends.debian.org/blends/1.1
>     then the priorities will be lowered when read:
>       □ Recommends –> Suggests
>       □ Depends –> Recommends
>
> May be this is not yet adapted to what I wrote before but this is not
> correct.

I forgot to change the docs here. Fixed in the repo.

>> > I admit this json is of different nature and could be used in connection
>> > with any different method to obtain the Git-based data.  I'm just
>> > afraid about changing something that is *really* rarely used and simply
>> > works just for the reason to make it more elegant.
>> 
>> Sure. I am however not sure whether this is true for generating the
>> changelog entry. Maybe I just add this to blends-gen-control.
>
> May be its a compromise to do the changelog generation based on the
> Git tags.  Probably it would not be a big issue to either hide the
> json files in a separate branch - or may be only exclude these from
> the generation of the source tarball.

Why should one do this? Additional files for local purposes can always
be in the sources.

>> BTW, are you happy with the UDD support? Or do you think we need more
>> here?
>
> I admit I do not fully understand what you mean by "initial package
> list".

I don't want to query all packages, but only those which are in the
blend. Therefore, one needs to give this list, which is then used as
input.

I however meant the blends-gen-control utility itself, not the package.

>  Please note that for the web pages I've crafted quite complex
> queries which gather way more data than will fit into an ordinary
> apt.Cache.  So if the paragraph
>
>    blends.uddcache(release, packages, **db_args)¶
>
> is just for the metapackage creation and if it ends up in arch dependant
> metapackages I'm perfectly happy.  But I can not really tell whether we
> need more here from the information I have.

Yes, it is for the metapackage creation only in the moment, and it
contains the versions for all archs (but only for the selected release).

For the web page, this needs probably to be extended to return the
packages for all (or a list of) Debian releases.

Also, for the web page this is however only what we (probably) need to
gather from the "packages" table. One would (in a similar manner) need
to select from popcon etc. And probably you want to create the Blends
infrastructure itself ("Blend", "Task" objects) from UDD instead of from
the files.

So, there is clearly some work for the web pages; the main idea in
blends-dev is to create some common infrastructure so that blends
related stuff does not need to be developed from scratch again.

So, I will now add a "python3-blends" package, which however needs then
to go though NEW... If then everyone is happy, we can move back to
unstable.

Cheers

Ole


Reply to: