Comps/groups/tags-concepts [Was: FESCo Meeting Summary for 2008-10-29]

[Les Mikesell]

Seth Vidal wrote:
>>
>> The thing I've always wanted is:
>>
>> Duplicate the installed packages on this other, existing machine
>> with options as to whether you want the same package versions or the 
>> currnt versions.
>>
>> And done in a way where the existing machine publishes it's list so 
>> the person installing just picks the example instead of wading through 
>> the thousands of packages every time.
>>
>> Bonus points for installing from the same repositories as the original 
>> packages...
>>
>> This could replace the concept of 'spins' with a minimal install and a 
>> command that says 'make it like that one' that someone with some 
>> expertise has configured for a similar purpose.
>>
> 
> That's really off-subject, though. That's something you do WITH the 
> metadata, not how to format the metadata to begin with.
> 
> And the above is doable as things are now, it's just not been written.

Yes, it 'could' be done, except for yum knowing which repository should 
supply which package, but until someone puts a 'publish my packages' 
button somewhere it isn't going to replace spins or allow people with 
configuration expertise to guide others without.  And I don't see a 
convenient way for the recipient to make the choice between matching 
reves or not.

> Tag-based viewing isn't doable now.

Can it span repos nicely?  How many different people will be able to add 
tags to get a package included in a group where they would like to see 
it?  This isn't something that 'belongs' to the package, it is something 
that relates more or less arbitrarily to the planned use of the machine 
and needs to arbitrate among equivalent packages.  How would you tag 
something related to being a mail server, for example?  If you have to 
know the difference between postfix and sendmail you've lost any 
advantage that tags might provide.

-- 
     Les Mikesell
      lesmikesell at gmail.com