Re: [devel] Re: Abstraction over Debian Packages in Kapture

On Mon, Jan 12 at 14:16, Dominique Devriese wrote:
> Marcin Pawlik writes:
[...] 
> 
>> I'd have to check it. I have never found time to dig deep enough
>> into libapt structure but I always thought the descriptions are
>> present in the apt binary cache exactly like other data is. 
> 
> Well, they aren't.

[...]
>> Hmm, Anaconda? It's already ported to Debian :)
> 
> AFAIK, anaconda is an installer, and we're talking about a package
> manager. 

Some kind of package management is also performed by installer so it's
not completely irrational. But you're right here and above, I've found
it after sending mail you are answering - see my responses to it.

>> This list shouldn't be taken as the reference since it reflects only
>> a particular Live CD development snapshot. There are many packages
>> that we will remove and many absent we will add. But I agree the Live
>> CD can be taken as the first selection draft.
> 
> Yes, of course, I was taking the livecd package list only to estimate
> the number of packages that would be necessary in our list.

Hmm, I think Knoppix could be better for it now. This list is just still
too random. The second problem with Live CDs is that during their
creation space has the exact limit. Some very useful packages cannot be
placed because they turned out to be too large when their inclusion was
considered and some useless ones are there only because a few megabytes
are left and they can fit there. This of course does not change the fact
that the selection is made and is a good starting point.

[...]
>> This package management menus will not be used every day so
>> entry access can be somehow slower. 
> 
> Sorry, I don't understand this sentence.  Entry access ?

I meant time needed to access a menu entry. Nothing technical :)

>> If you also want to group the packages, it can be easily achieved by
>> dependency pseudo-packages like for example koffice.  The problem
>> with it is that when you uninstall the package its dependences are
>> not uninstalled so maybe this is something the package manager also
>> should take care of.
> 
> Yes, I am not sure whether it would be possible to provide and
> continue to provide a perfect mapping from our concept of packages to
> Debian's,

I think forcing one-to-one mapping here isn't a good idea.

> so maybe we should drop the immediate correspondence, and make our own
> packages tree, where each of "our" packages specifies what debian
> packages it "depends on".

Probably. And I think they shouldn't be the real debian packages like
koffice from my example but rather all be placed in the single
installer-mappings package. There would be just too many of them.

Regards,

-- 
Marcin Pawlik