[Mageia-dev] RPM features/issues/wishlist

[Per Øyvind Karlsen]

2011/10/14 Donald Stewart <watersnowrock at gmail.com>:
> On 14 October 2011 11:36, Samuel Verschelde <stormi at laposte.net> wrote:
>> Le vendredi 14 octobre 2011 20:33:29, Per Øyvind Karlsen a écrit :
>>> 2011/10/14 Samuel Verschelde <stormi at laposte.net>:
>>> > Le vendredi 14 octobre 2011 19:30:01, Samuel Verschelde a écrit :
>>> >> Le vendredi 14 octobre 2011 16:19:18, Per Øyvind Karlsen a écrit :
>>> >> > I've started to ramble on some of the features, issues, ideas etc. to
>>> >> > work on and consider
>>> >> > for our (Mandriva Linux) next development cycle, and in the interest
>>> >> > of sharing work and
>>> >> > coordinating efforts with others, while inviting others to contribute:
>>> >> > http://wiki.mandriva.com/en/Development/Tasks/Packaging/Tools/RPM/TODO
>>> >> >
>>> >> > While it's certainly written from a vendor POV (and also rather crude
>>> >> > for the moment), I'm cross-posting
>>> >> > this one as it's of potential interest to others as well and the idea
>>> >> > is for things to be as generic as
>>> >> > possible anyhows.. :)
>>> >> >
>>> >> > So I invite others with the interest to contribute to the discussion
>>> >> > on the list and wiki, proposing
>>> >> > ideas, gather a list of issues that needs to be addressed, and do some
>>> >> > general brainstorming
>>> >> > and uhm.. "stuff". ;)
>>> >>
>>> >> I don't know RPM internals well, the only thing that comes to my mind is
>>> >> improved packagekit support for Mandriva / Mageia.
>>>
>>> Don't necessarily need to know RPM internals for proposing features,
>>> or issues you'd
>>> like to see be solved. :)
>>>
>>> > Maybe also the package management related items in the Mageia 2 specs can
>>> > be of interest:
>>> > http://mageia.org/wiki/doku.php?id=iso2:technical_specification#package_m
>>> > anagement_infrastructure
>>>
>>> Ah, yes, most certainly. :)
>>>
>>> I can leave some comments on your wiki, while adding what I personally
>>> find useful and interesting to my
>>> wiki page where I'll keep track of it's current progress (at my end at
>>> least;).
>>
>> Please note that this wiki page is readonly (don't trust the wiki if it lets
>> you edit it). The place for discussion is bugzilla (each item should have an
>> entry in bugzilla, even if it's not the case currently).
>>
>> Best regards
>>
>> Samuel
>>
>
> Improving packagekit would be great, not having a qt based package
> manager is annoying.
Yupp, you'll find several new features the urpmi backend was lacking
implemented in my branch.
Keep in mind though that packagekit is designed in a very generic way,
with the features that packagekit lacks, it's not as simple as just going
ahead and implement it in the backend, support also needs to be
implemented in the frontend as well.
And if you want some new feature making it into packagekit upstream,
you need to have some consencus on it and take other distros into
consideration as well, so there might potentially be features of rpmdrake
that will be hard, if ever to get properly implemented in packagekit
and maintained upstream..

In the scenario for how I'd like to see packagekit adopted for Mandriva and MPM
for instance, I'm kinda expecting having to go ahead and just
implement and maintain
some features in our own backend only that might not be part of
packagekit's features
or supported by other frontends for it etc. (at least not immediately).

Well, that's just some thoughts I've had on the potential challenges
of packagekit
and to warn against having too high expectations towards packagekit
frontends replacing
existing ones.. :)

Is there any particular features in the packagekit feature matrix
you're missing btw.?
('what-provides' has already been implemented in my branch </FYI>:)
>
> The only other thing that I would like to see, although i think it is
> more or a urpm issue than rpm is adding parallel downloads, so that
> when packages are being installed, it keeps on downloading the next
> set to be installed.
Yupp, already on urpmi's suggested feature list since a while ago,
although it would have
to be implemented at a much higher level in urpmi perl code by adding
separate threads
downloading and package installation.. I'm a wuzz at perl and awaiting
for a new perl
maintainer to arrive to hand of such very perly details to implement,
so it's on the list,
but likely not to be done (in urpmi) by me. :)

--
Regards,
Per Øyvind