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

Re: Metapackages in "Section: metapackages" or not (Was: visibility of Debian Pure Blends)

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


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: