Re: Metapackages in "Section: metapackages" or not (Was: visibility of Debian Pure Blends)
On Mon, Oct 27, 2014 at 02:06:08PM +0100, Jonas Smedegaard wrote:
> Quoting Markus Koschany (2014-10-27 13:09:09)
> > On 27.10.2014 11:04, Jonas Smedegaard wrote:
> >> Quoting Andreas Tille (2014-10-27 07:19:27)
> >>> On Sun, Oct 26, 2014 at 10:06:50PM +0100, Jonas Smedegaard wrote:
> >>>> Quoting Andreas Tille (2014-10-26 17:17:37)
> >>>>> It is not mandatory by blends-dev. [implementation details
> >>>>> skipped] For me it becomes more and more evident that we need to
> >>>>> discuss more on this list about needs of different Blends and how
> >>>>> to correctly implement this.
> >>>> Well, one reason for lack of discussion in the past is that (as far
> >>>> as I am aware) only one tool for creating blends have existed:
> >>>> blends-dev.
> Let me clarify: *My* reason for not taking part in many discussions here
> in the past have been the above.
Ahhh, that 'My' is a very important detail in your statement.
> >>> I see it differently. I would have loved to discuss about features
> >>> of blends-dev but the responses in the past tended to be zero. Not
> >>> even bug reports about features were filed. So I try to "overhear"
> >>> what might be needed and #720199 was the actual motivation to
> >>> implement the feature to add "Section: metapackages".
> >> I am not surprised that you are blind to the reason I bring up.
> Let me clarify: Strange how my actual reason can be "seen differently".
> Gotta be something else that is seen differently - perhaps simply that
> Andreas is not looking at all (read: not really commenting on what I
> wrote), but instead continues to talk about his original point.
The idea of this list was to discuss about common things between all
Blends. Your statement sounded as if this discussion only makes sense
if different tools exist. Do you consider "disagreement with your
point" as "talk about my original point"? I admit that I remain
perplexed if running a GSoC project with the goal to redesign a tool
does not trigger any discussion since only an alternative tool is worth
discussing according your point of view (or do I missunderstand it
> > I think you misunderstood Andreas statement above and sensed something
> > negative which wasn't there in the first place.
> What I sense is that Andreas and I talk past each other.
> And I sense
> frustration about lack of collaboration in evolving the tool(s) for
> making blends. The latter contributes, I guess, to the former.
Well, its not so much the frustration about a lack of collaboration in
evolving the tools. The tools evolve and find their users and I have
fun with the development. (=not more frustration than the usual
development might bring. ;-))
I'm just astonished / speachless / perlexed if people are not
communicating their feature requests. And I admit that the reason
you gave that communication only happens if there is an alternative
implementation makes me shaking my head even stronger than a simple
lack of interest / time.
> > Although I am quite new to the project, I have no doubt that all
> > Blends projects could discuss any kind of problems with the tools on
> > this list and find a solution that benefits them all.
> I completely agree.
Since I know you for a long time and you were helpful in the very
beginning I assumed this. :-)
> > However to start any kind of improvement you must be aware of that
> > something needs to be addressed. That's the simple quintessence of the
> > above paragraph.
> Not sure what you point is with above.
> If you mean to imply that that improvements on how to make blends is
> quintessential to discuss on this list, then I disagree.
At least I'd regard it sensible to discuss on the list - which is
what I intended to say.
> > For me and Debian Games blends-dev just works. I can also live with
> > Section: metapackages because it seems to be the obvious place for
> > metapackages. When I want to remove all packages in one go, I run
> > »apt-mark auto <metapackage«.
> That sounds strange to me (and is independent on use of blends-dev or
> not): Do pulled-in packages really get removed too with "apt-mark auto
> <metapackage>"? I fail to follow how that can be possible: When APT
> skips making a note at install time that a package is auto-installed,
> how can it be sure that that package is ok to remove again, just because
> it happens to be part of a metapackage getting removed? What if same
> package is also pulled in be other metapackages not being removed?
> > It is quite understandable that different people and projects have
> > different needs but I don't see a reason why we could not discuss
> > flaws in blends-dev and try to fix them, so that all projects will see
> > improvements not only a single one.
> Neither do I. Not sure what your point is.
I guess Markus' point is the same as mine: We all are keen on learning
what the problem is that boxer solves but blends-dev not. 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.
> If you have read my previous posts as being against collaboration, then
> that's a misunderstanding: I merely explained one (real, not
> theoretical) reason for the lack of some expected/wished collaboration
> in the past, not a reason to avoid collaborating as a principle.
Jonas, I know you for years and made friend with you because I consider
you always helpful and definitely not against collaboration. That's not
the point. I also do not think that we should spent our time on
discussing failed communication. Just let us enhance it from now on.
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?
- Re: Boxer
- From: Jonas Smedegaard <firstname.lastname@example.org>