Re: New feature for 0.6.103
On Tue, Apr 10, 2018 at 01:11:13PM +0200, Ole Streicher wrote:
> > 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.
Either something is wrong with your certificate or (more probable)
somehow our firewall has not updated certificates.
> > 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.
Thanks.
> >> 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.
Sure. I have no problem with this (otherwise the files would not be
there). I assumed you would not like these files. :-)
> > 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.
You can do so by joining for instance
select * from blends_dependencies where blend = 'debian-astro';
Drawback: The UDD importer needs to be triggered to get your latest
changes. Example queries can be found in blends-gsoc. The strategy for
blends-gsoc was: UDD knows the content of your tasks and fills the table
accordingly. The importer works relatively fast since it keeps a hash
of the last import and imports only if the has has changed.
Attention: The importer[1] has only 'r' and 's' as dependency key - so
for format 1.1 it needs 'd' as well.
> > 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.
I think we should stick to the well tested UDD queries. It was quite
some work to write these. The only change I have in mind is to restrict
the version query to unstable, testing, stable, oldstable and
exprimental (currently it returns everything in UDD). May be we should
also return only one version per release (sometimes kfreebsd or hurd
is lagging behind and we have several entries for sid).
> 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.
ACK.
> 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.
Fine for me.
Kind regards
Andreas.
[1] https://salsa.debian.org/qa/udd/blob/master/udd/blends_metadata_gatherer.py
--
http://fam-tille.de
Reply to: