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

Re: Boxer

Quoting Andreas Tille (2014-10-27 20:41:21)
> 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.
[GSoC frustration venting snipped]

Nice to know, in case I should want to dive into that codebase.

>> - 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.

That is not the point.  Yes, I am being 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.

Debtags is on my radar too for boxer, but further down the line.

I suggested Enrico to use DebTags for package selections at DebConf 5.  
Back then he also judged DebTags unfit for that purpose, but I suspect 
he simply didn't see the full picture (read: I failed to share my idea): 
Package selections are finite and Debconf open-ended by design, and 
therefore suitable only as guidance at most - which is how I intend to 
use it.

>> ¹...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).

I am not talking about arch-dependant metapackages, but ways to generate 
a root filesystem (which for cross-arch involves invoking multistrap, 
and for my high goal doing that without the need of real root, which is 
possible but quite complex to do right).

> [...] I'd suggest you should add these two Blends to 
> http://blends.debian.org/ to let users know about these new Blends.

DebianParl is not a collection of packages - I consider it distracting 
and arguably even damaging to emphasize that aspect for DebianParl.

Is it possible to add a blend to that page promoting not metapackages 
and bugs but only Homepage of the blend?

NB! No need to tell me how code is open for changes and I am free to 
restructure: I know that anything is possible given enough amount of 
time and energy to convince peers to move in a certain direction - my 
question is *not* whether it is possible for me to invest time and 
efforts in changing structures to make it fit my different needs.  My 
question is whether that is possible _without_ me allocating resources 
to it.

[more frustration venting snipped]

> > > 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:
> > 
> > <https://wiki.debian.org/Boxer>
> > <https://metacpan.org/pod/distribution/Boxer/bin/boxer>
> > <https://anonscm.debian.org/cgit/boxer/boxer-data.git/tree/README>
> > 
> > Here's the more elaborate README from initial draft, more about the
> > deployment features not yet re-implemented in current codebase: 
> > <https://anonscm.debian.org/cgit/boxer/boxer.git/tree/README>
> Ahh, you moved away from
> $ apt-cache showsrc boxer | grep ^Vcs
> Vcs-Browser: https://anonscm.debian.org/cgit/pkg-perl/packages/boxer.git
> Vcs-Git: git://anonscm.debian.org/pkg-perl/packages/boxer

No, those URLs are packaging URLs and still valid.

> Before I clone from the new location: Is there any reason not to use 
> git://git.debian.org/git/blends ?  I'm just wondering ...

Yes, there are reasons for that, but I am not in the mood: Branching is 
cheap - go fork the code if important to you to have it there.

NB! I do notice that you are "just wondering".  But I also know that you 
quite likely will ask further on any reflections I provide - or others 
will.  Which is perfectly fine, but consumes time and energy.  I want to 
do more fruitful stuff than defend a choice of git location.

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature

Reply to: