[Mageia-dev] RPM features/issues/wishlist

Sat Oct 15 01:13:23 CEST 2011

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
+