Re: New feature for 0.6.103
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.
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. In Format 1.0 Recommends and Depends are synonyms. If a
dependency exists both end up in Recommends if not both end up in
Suggests. Its just that a 1.0 format task file never can produce any
"Depends" in the control file output.
> >> We already have git, so creating a function that returns a
> >> `blends.Blend` object based on some git tag (rep. Debian version) is
> >> straightforward with `git worktree` and also (since the blends source
> >> packages are rather small) quick. And has the advantage that you don't
> >> need to maintain an additional json file. You can just generate it on
> >> the fly ;-)
> >
> > I confirm that I understood that it is possible to do this. However, I
> > can not imagine that whatever kind of diff between tags will be used
> > this is faster than just reading a json file.
>
> It is not faster; it is probably just not much slower.
Its definitely slower when you put the development and testing time into
consideration. :-P
> > In addition I would need to "fake commit" pre-version control data
> > into Git (yes, there were releases of Debian Med before I started
> > using SVN). These are now simply stored in json that's aggregating
> > the data I want to display[1].
>
> That is ofcourse a good argument, and also maybe the blends class cannot
> read all the really old data.
I would not mind to fake those commits if the original packages would
be available any more. But some of these even pre-date snapshot.d.o.
> > 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.
> 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". 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.
Thanks a lot again - I'm really happy that your are doing that stuff
Andreas.
--
http://fam-tille.de
Reply to: