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