[Mageia-dev] RPM features/issues/wishlist

Sat Oct 15 01:32:41 CEST 2011

On 14 October 2011 16:13, Per Øyvind Karlsen <peroyvind at mandriva.org> wrote:
+> 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
+>
+
+The thing about packagekit, well most graphical frontends package
+management (pm) is that they dont really need to be that functional.
+By that I mean that yes it is great to be able to query nearly all of
+urpmi's features in rpmdrake, however, isn't it much faster to just do
+urpmf --files file-name. I guess what I am getting at is that as long
+as basic functionality, eg searching, add/remove and repo
+configurations are handled by the pm and done properly, ie not causing
+any breakage, then I feel that it is fair enough to say that more
+advanced functions should be done on the cl, firstly because that way
+is easier, secondly because that way encourages less breakage from
+just point and click and see.
+One feature of rpmdrake that i do really like is that you can
+configure it to search by {name,description.......} this helps a lot
+for finding software that you don't know the specifics for before
+hand, and the only real case where a gui frontend comes into its own
+for pm so I guess that as long as that is supported, with being able
+to see arch, and release numbers, I am happy to have a basic pm
+system.
+
+I remember seeing that list somewhere, hence why i wasn't sure. Well,
+I am about as good at speaking pearl as i am at finding perl's so i
+guess that counts me out :)
+