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/005419.html | 218 +++++++++++++++++++++++++++++++ 1 file changed, 218 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005419.html (limited to 'zarb-ml/mageia-dev/2011-June/005419.html') diff --git a/zarb-ml/mageia-dev/2011-June/005419.html b/zarb-ml/mageia-dev/2011-June/005419.html new file mode 100644 index 000000000..6136525dc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005419.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

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

+ andre999 + andr55 at laposte.net +
+ Sun Jun 12 06:52:27 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+> 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).
+
+Not only would users tend to avoid backports, they would tend to avoid Mageia after a bad experience.
+
+>  > > 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.
+
+Exactly.  Backports supported, but to a lesser degree.
+
+>  > > 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
+
+I think that this is a good approach to the issue.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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