On Mon, Oct 27, 2014 at 04:16:51PM +0100, Jonas Smedegaard wrote:
> > We all are keen on learning what the problem is that boxer solves but
> > blends-dev not.
> My reason for creating boxer from scratch rather than extending
> blends-dev is part practical - Python is too alien for me
Current blends-dev is written in Perl and sh. There would have been a
time to rise your voice about this once GSoC was started. While there
has been a preference for Python nobody in the team has ever questioned
this. This is what I mean by communication failure. :-(
> - and part
> conceptual - I want the tool centered around the process of composing¹ a
> blend rather than on fixating a blend once composed.
This somehow smells like DebTags ... just guessing since your
statementes are a bit vague. Since I bring in this term: I confirm that
I was a long time thinking about involving DebTags into the Blends
framework until I had a talk with Enrico 'DebTags-Master' Zini at
DebConf 13. He quite clearly declared that tasks are something else
that you definitely *should* fix them and DebTags fits a different
purpose. Well, this does not really draw me away from the DebTags idea
but it not the right method to create metapackages.
> ¹...and other aspects than composing too: deploying - in particular
> deploying from one architecture (amd64) targeting another (armel) - was
> the focus of previous drafts implementations, for use with FreedomBox.
Interesting: One major feature of the GSoC project was to have
architecture dependant metapackages (since not all dependencies are
existing on al arches).
> Here's what boxer can do - have done - as developed so far:
> Boxer composes blends from class definitions.
> DebianParl blend took ~6 months to compose (after ~3 years of drafting
> its concept), as basically a slim Xfce desktop with few refinements and
> a few specific packages added.
> Debian Design took 2 days to compose (after ~8 months of drafting its
> concept), as the already refined and tested Xfce classes of DebianParl +
> a few specific pakcages added.
> Onwards, refinements of DebianParl will also refine Debian Design.
> Anyone can benefit from same refinements by use of the boxer-data
> package - if agreeing with its implicit choices favoring lightweight
> over heavy and GTK+ over Qt. Or use only the boxer tool, developing an
> independent set of classes with other choices.
I need to have a look into debian-parl and debian-design source to
understand things better. In any case I'd suggest you should add these
two Blends to http://blends.debian.org/ to let users know about these
> > May be more Blends developers do have the same problem or might run
> > into it later. Was there any chance to solve this problem in the GSoC
> > project? etc. So I keep on failing to understand what exactly was
> > stoping you to drop a note here about what you are doing.
> What stopped me was lack of ability to express what boxer was in my head
> back then and (even more) lack of ability to describe what boxer has
> become so far.
> No doubt that GSoC could have been better if I was not me but someone
> else with different capabilities and visions. :-P
I usually like your visions. ;-)
> I never had a vision for GSoC to help improve current tools in this
> team. So please do not put it on me how that turned out.
I do not put in on you since in free software world you can never blame
anybody for not doing a certain thing. I simply was astonished what
reason you gave for what I personally would call a failure of
> > I tried to find some documentation about boxer but did not found
> > anything which makes it clear to me what problem it solves and how it
> > compares to blends-dev. Could you please be so kind to enlighten the
> > list about this?
> Boxer is young, has radically shifted form during its 3 years of
> evolution, and I am lousy at documentation.
> Here are some pointers:
> Here's the more elaborate README from initial draft, more about the
> deployment features not yet re-implemented in current codebase:
Ahh, you moved away from
$ apt-cache showsrc boxer | grep ^Vcs
Before I clone from the new location: Is there any reason not to
use git://git.debian.org/git/blends ? I'm just wondering ...
- Re: Boxer
- From: Jonas Smedegaard <email@example.com>