[Mageia-discuss] Suggestions

[andre999]

Kira a écrit :
>
> 在 Tue, 26 Oct 2010 13:22:52 +0800, andre999 <andr55 at laposte.net>寫道:
>
>> I don't quite follow this distinction of programs and packages.
>> A package is a file with installation instructions for a program, or 
>> a set of closely related programs.  Sometimes a program with many 
>> modules is divided into more than one package, but then there are one 
>> or more core packages, essential to the installation of the others.
>> So maybe some packages would need minimal documentation since they 
>> are dependant on a core package (e.g. OpenOffice).
>> But if considering installing a package containing a number of 
>> closely related programs, wouldn't one want all the contained 
>> programs to be documented ?
>> Since they would almost necessarily be complementary ?
>> And if you install only one program at a time, essentially you are 
>> saying that each package contains exactly one program.  So you want 
>> 37 packages to install Openoffice ?  And you want 4 or 5 packages 
>> instead of one for the diff (file comparison) utilities ?
> The difference is clear: For most of the time, you would install 
> programs,
> not packages. Currently in the RPMDRAKE, libraries are listed, 
> localizations
> are listed, which is annoying since if you are not programmer, why 
> would you
> cares about these things? Sure, some would need them for their own 
> purpose,
> but most of the time we would only focus on install certain program, not
> related libraries/localizations/....etc. They should go into expert mode/
> detail mode, not directly exposed to people. This is a usability 
> problem, not
> about packaging.
It is essential to be able to readily select localisations, for those 
needing something other than English.
>
>> By the way, if newbies are scared off by packages, why is the 
>> Microsoft environment package oriented ?
>> (Even though often a package of numerous programs is referred to as a 
>> program.)
>>
> I think you miss-understand my thought. That's something like task 
> package,
> which is not what I was talking about. I meant the packages like 
> libktorrent,
> which is installed together with ktorrent as the backbone library. 
> It's listed
> in RPMDRAKE, but in what normal condition would you install it solely?
> NO. You install KTorrent, not libktorrent. It should be hidden by 
> RPMDRAKE,
> unless you check the option to show all packages. Most of the time, 
> you won't
> care about what packages installed on your system, you cares about what
> "softwares" are installed.

OK, I understand now.  You want to show only ordinary program packages, 
and not libraries or localisations.
But libraries are in their own section, if you list packages by category.
And localisations are useful packages to show, unless you want to 
install them all.
Or you have another way to ensure that only wanted localisations are 
installed.
That could be useful.

This reminds me of a suggestion I made a while back for rpmdrake -- that 
packages can be grouped multi-level, such that related packages, such as 
localisations or modules of a package, be folded to a single line (or 
expanded to multiple lines), to greatly reduce the number of lines 
displayed.
(e.g. Openoffice or Firefox.)
To accommodate this, Rpmdrake would have to be modified to have multiple 
(2 or 3) selection columns.  One could select multiple packages with one 
click, if folded into one line, or expand the line to select only one or 
a few of the packages inside.
A good example would be Openoffice, could now be displayed by default in 
only 3 lines : the base package, the various modules (Writer, Calc, 
Draw, etc), and the localisations.  One could select the base and 
modules in 2 clicks, and open the localisations to select the 
language(s) desired.  Instead of seeing approximately 100 lines.
(I just counted, probably miscounting a bit.  In fact it was about 300, 
as there were the release and 2 updates for each package.)
Note that many related libraries are divided into a number of modules as 
well, so the same principle could apply there.

Anyway, however we do it, there is definitely room for improvement in 
Rpmdrake. :)

- André