[Mageia-dev] How will be the realese cycle?
ahmadsamir3891 at gmail.com
Thu Oct 14 16:00:50 CEST 2010
On 14 October 2010 15:41, Tux99 <tux99-mga at uridium.org> wrote:
> Quote: Buchan Milne wrote on Thu, 14 October 2010 15:27
>> What aspects of the Mandriva backports solution are not satisfactory?
>> -The fact that not everything is available as a backport?
> Yes, more packages should be available
> (and as future packager I will do my part to make that happen)
Well, backporting a package is a one-liner, so it takes less than
minute to be done; that's not the issue. The issue is that a new
version of package A may need a new version or package B to work, so
package B needs to be backported too; and/or that the new version of A
doesn't work with older libs/kernels, so backporting isn't too much
time consuming for packagers, but making sure that that backport has a
good chance of working(tm) is the bigger burden/responsibility.
I've seen, too many times, trigger-happy packagers backporting
packages that're not maintained by them (so they know it less than
those package maintainer(s)), breaking those packages and annoying the
maintainers of said packages. It's usually irresponsible to backport a
package without taking that package maintainer's opinion into account.
(an infamous example on that is gwibber being backported to 2010.1).
>> -That users don't know how to request a backport?
> It certainly could help publicizing backports and giving the user an easy
> way to request specific packages
New users who frequented the forums always got to know what backports
are pretty fast. And bugzilla is the perfect system for asking for a
backport, that worked pretty good.
>> -That users aren't aware of backports?
> Yes, backports should be promoted better in drakrpm and in the web site.
>> -Something else?
> backports should be supported for security patches and bug fixes just like
> the main packages (if not instead of the main packages).
> Of course the security patch could be simply provided by backporting a
> newer version of the package, no need to make patches for each version.
That's they way backports has always worked, no specific patches, just
the latest cooker package pushed to backports "as is with no official
support", that's reasonable, packagers shouldn't promise to support
backports when they can't due to various reasons (time, effort.. etc).
>> > The end users need to do less than now for to get new versions of
>> > their
>> > favourites applications.
>> Less than 'urpmi --searchmedia Backports chromium' ?
> CLI is not ideal for 'normal' users.
rpmdrake has a "Backports" filter that shows packages from backports
repos, that's easy to use even for new users.
>> Or, should it be more obvious in rpmdrake or similar?
> I think they should be enabled by default, since it's my impression that
> the majority of 'normal' users wants new versions of apps, those users who
> DON'T want them can still always disable them.
> Backports shouldn't be second choice, it should be the default, since that
> would make Mageia stand out from other distros as being the distro were
> users get the latest versions of apps before any other major distro
> provides them.
Enabling them by default defies the purpose of having backports at
all; it's not for new users, it's more for slightly experienced users
or power users who want the latest versions of apps.
More information about the Mageia-dev