From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-June/005410.html | 212 +++++++++++++++++++++++++++++++ 1 file changed, 212 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005410.html (limited to 'zarb-ml/mageia-dev/2011-June/005410.html') diff --git a/zarb-ml/mageia-dev/2011-June/005410.html b/zarb-ml/mageia-dev/2011-June/005410.html new file mode 100644 index 000000000..5523b75af --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005410.html @@ -0,0 +1,212 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Jun 11 18:03:12 CEST 2011 +

+
+ +
Le samedi 11 juin 2011 18:01:54, Maarten Vanraes a écrit :
+> Op zaterdag 11 juni 2011 16:55:00 schreef Samuel Verschelde:
+> > Le samedi 11 juin 2011 14:26:19, Maarten Vanraes a écrit :
+> > > Op zaterdag 11 juni 2011 13:14:29 schreef Samuel Verschelde:
+> > > > Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
+> > > > > On Fri, 10 Jun 2011, Michael Scherer wrote:
+> > > > > > We can agree that everybody want something newer for some rpms,
+> > > > > > but few people want everything to be newer ( ie, now one run
+> > > > > > backports as a update media, I think ). So as much as I am
+> > > > > > against asking to users questions, we must show them the choice
+> > > > > > somewhere, in a non obstrusive way.
+> > > > > 
+> > > > > Maybe, but how would be "support" this? We must be able to
+> > > > > reproduce a reported problem. This becomes complicated when we
+> > > > > don't know what is installed on the user's system. A guideline for
+> > > > > bug reporters is (or should be) "make sure you installed the
+> > > > > latest updates". What would be the equivalent for backports? I'm
+> > > > > afraid it should be "if you installed any backports, make sure you
+> > > > > installed all backports that are relevant for your system". If
+> > > > > someone has a problem with any other combination, the bug report
+> > > > > might be rejected. How would QA even work when only selected
+> > > > > packages are upgraded from backports, or integration testing:
+> > > > > integration with what?
+> > > > > 
+> > > > > So the only combinations we can support are:
+> > > > >    - release + updates
+> > > > >    - release + updates + backports
+> > > > > 
+> > > > > More practical: for mga1 I have a VM that I can keep updated. For
+> > > > > mga1 backports I can install another VM with backports enabled. But
+> > > > > for bugs reported with only selected backports installed I suppose
+> > > > > I would have to install a new VM with mga1, update it, and install
+> > > > > only those backports -
+> > > > > 
+> > > > > for each bug report. But maybe I'm missing something, please
+> > > > > explain.
+> 
+> (:
+> > > > If we suppose that either updates or backports are supported (with a
+> > > > support level to be defined), the situation is simpler to me :  a
+> > > > good backport must work  with all its dependencies coming from
+> > > > updates or release OR it must explicitly require higher versions,
+> > > > found only in the backports media and so automatically pulled.
+> > > > 
+> > > > So I don't think that having picked up only certain backported
+> > > > packages is a problem for the maintainer's support. Maybe I
+> > > > over-simplified the situation, but I don't think it will be as
+> > > > complex as you say.
+> > > > 
+> > > > Samuel
+> > > 
+> > > imho this creates more work for packagers or qa team to support
+> > > backports, i'm not really in favor of this solution
+> > 
+> > So it someone has a problem with a package you backported and reports it
+> > in bugzilla, you'll answer "not supported" and close the door ? Then we
+> > have not a single chance to have users accept to use backports rather
+> > than ask for a rolling release (supposing that we want to stay with
+> > stable releases model, which hasn't been decided yet).
+> > 
+> > In my opinion, a backport must be either supported or not exist. Even in
+> > Mandriva, where everybody keep saying "backports ain't supported",
+> > usually people try to solve the problems caused by backports.
+> > 
+> > However, the level of support can be different between backports and
+> > updates, as I said in my previous message. The differences are yet to
+> > define, but here are some I see :
+> > - when a critical bug in a backport exists, you can simply update to a
+> > newer version and see if it's solved
+> > - if the program already is in its the latest version and has an upstream
+> > bug, you can answer "report the bug upstream" and stop there until
+> > upstream solves the bug. For packages in release or updates, ideally you
+> > have to try to help fixing it or work it around because the bug is
+> > considered part of the whole distribution.
+> > 
+> > Best regards
+> > 
+> > Samuel
+> 
+> What about security fixes? if there's 1 version in release and 10 in
+> backports? do the older backported packages have to be securitypatched?
+> 
+> imho not supported backports means that if backports has an issue, try a
+> newer backports...
+> 
+> imho that is a good level, that doesn't require much effort.
+
+I think we agree, because if we follow the Mandriva way, upload of a new 
+backport for a given package removes the old one if there is one. So at a 
+given time, you only have to support the package in release or updates + 0 or 
+1 backport.
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110611/cd906686/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1