[Mageia-dev] RPM features/issues/wishlist

[Donald Stewart]

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 :)