On 27.10.2014 14:06, Jonas Smedegaard wrote: >> Quoting Markus Koschany (2014-10-27 13:09:09) [...] >> 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. That was also my impression but I think we are on the right track again. :) >> 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. What I meant is that the outcome of this discussion is not the important point because personally I have no preferences for certain tools be it blends-dev or boxer. I just want to get a job done in the least amount of time. However I can understand Andreas' frustration because there was this GSoC project and we have a dedicated mailing list for Blends and also Debian's bug tracker. So I would expect that people raise their concerns here, file corresponding bug reports and present possible solutions. My point is that you can't fix something without knowing that it is broken. >> 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? > Hmm, I was quite sure that apt-mark auto <metapackage> was the key to success the last time I tried to remove all my dependencies of a metapackage. I have probably done something extra but can't remember what it was anymore. What definitely works is taskel remove <metapackage> but be careful there is no further confirmation prompt. >> 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. > > 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. No, I didn't read it this way. I was just under the impression that both of you talked past each other. What I am personally interested in is to know what exactly is missing from blends-dev, where are the bugs, how can they be avoided, what features are missing, how is the work flow of other projects and so on. Then I could possibly participate in finding solutions. Markus
Attachment:
signature.asc
Description: OpenPGP digital signature