[Mageia-dev] Mirror layout, round two

Wed Dec 1 21:54:48 CET 2010

+Ahmad Samir a écrit :
+>
+> On 30 November 2010 07:29, andre999<andr55 at laposte.net>  wrote:
+>> Michael Scherer a écrit :
+>>>
+>>> Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit :
+>>>
+>>>> Yann Ciret a écrit :
+>>>>
+>>>>> I dislike the main/contrib separation in some case.
+>>>>> The first example is with Mozilla Thunderbird packages. Some extension
+>>>>> packages are in contrib. So each time thunderbird received security
+>>>>> update, the update cannot be installed because of non automatically
+>>>>> rebuild of his contrib package. And each time I see a bug report of user
+>>>>> asking a manual rebuilt. With only one core media, this situation will
+>>>>> disapear (I hope).
+>>>>
+>>>> Unlikely.  This problem is not at all related to separate repositories.
+>>>
+>>> It is. It is exactly related to the fact that thunderbird is supported,
+>>> and that extension are not despites depending on it.
+>>
+>> In this case it is evident that you don't understand how extensions work
+>> with mozilla products.
+>> Thunderbird will function correctly with no  extensions installed.
+>> So why should any extension block the update of Thunderbird ?
+>
+> So the user can simply uninstall that extension and update to new
+> thunderbird? the user can do this only if he doesn't need that
+> extension, only if it doesn't offer features he wants to use. That's
+> an invalid argument, if he doesn't need that extension why does he
+> have it on his system??
+
+You're missing some points here :
+1) There is no need to remove an extension.  It will continue to work, 
+as long as there hasn't been some error in packaging.  In other words, 
+on a generic Mozilla installation, it would continue to work.  The only 
+exceptions in the past are when Mozilla changed the version of XML used 
+to code extensions.  (Which has happened twice since the beginning of 
+Mozilla, if I recall correctly.)  But that would not happen on an update.
+
+2) If by chance the extension does not work properly, it can always be 
+updated directly by the update function inside Thunderbird.  Unless the 
+distro packaging has somehow disabled this function.  Which would be an 
+error in packaging.
+
+3) There is no reason to package Mozilla extensions in the distro, 
+except for base localisation modules, which are already in main.
+
+4) If an optional module of any application stops working, that can only 
+affect the application in question.  And should not stop the application 
+from working.  That does not in itself justify such an extension being 
+considered (logically) core.
+>
+> The rationale is/was that mozilla code breaks/broke ABI, so it was
+> agreed that extensions are rebuilt for both firefox and thunderbird
+> respective new versions.
+See above.
+>
+> We will look into that with upstream, so that if a rebuild isn't
+> needed, then all the better for us (packagers). But until that
+> happens, they will be rebuilt. A 1-2 day delay isn't too much for
+> users.
+Good.  Check with upstream.  It can be done quickly, and will help clean 
+the system.
+By the way, if you install Thunderbird, you can confirm the critical 
+elements yourself.  (Installation/update of Extensions and other 
+optional modules fully managable from inside Thunderbird.  As well, by 
+default there are automatic alerts when updates become available.)
+>
+> The more pressing issue is, what does this have to do with the topic
+> at hand "Mirrors layout, round two" ?? this discussion is deviating
+> too much, to the extent it's becoming bloated...
+
+Everything.
+Removing the distinction between core and non-core packages removes an 
+important control, useful to give greater assurance that (logically) 
+core packages are not broken, thus breaking users' systems.
+In my mind, alternative controls are likely to be more complex to 
+maintain, and probably less reliable.
+It is interesting that the names "core" and "extra" were chosen to 
+replace "main" and "contrib".
+Especially since "main" was originally meant to be core packages.  But 
+not enforced, as some packagers themselves have pointed out.
+(One would prefer that I don't mention his name.)
+>
+>> Additionally, modules installed will continue to work as long as the major
+>> version doesn't change.  (Actually slightly more complicated.)
+>> In some cases one won't be able to newly install a module because a config
+>> file inside the module - equivalent to the spec file in rpm packages -
+>> hasn't been updated for compatible versions.  (In fact, the versions were
+>> probably improperly specified.)  But installed modules will continue to
+>> function.
+>> It is possible that the packager did not realise this - or for whatever
+>> reason did not properly set up a spec file - but this issue has nothing at
+>> all to do with separate sets of repositories.
+>
+> Speaking abstractly without examples in this case is just that,
+> "speaking". Give us an example of such a case (if any) in a spec file
+> so that it can be fixed.
+More precise details added above.
+>
+>>> That precisely because we tell "security and bugfixes occurs only on
+>>> main" that contribs got broken, since the security team do not care to
+>>> not break contribs packages
+>>
+>> The crux of this problem is that core (in the general sense) packages are
+>> dependant on packages that are not recognized as core.
+>> That again has nothing to do with repositories as such.
+I should have said "packages in core", since many such packages aren't 
+really logically core to the system.
+>
+> I agree with Michael here, doing sec fixes isn't hard (once one gets
+> used to it), just time consuming, and it should be done for all
+> packages in the "official" repos; it's true that GPL gives no
+> guarantees what so ever, just it's a moral obligation for people
+> involved in the FOSS world to support users as best they can.
+I agree that security fixes should be done for all packages in 
+"officiel" repos.  (Meaning "core" and "extra".)
+But
+1) My main point is that priority should be given to truly core 
+packages, because, as you mention, it is time consuming.  If core is 
+mixed with non-core, that priority is (at least more) difficult to follow.
+
+2) An important part of my proposals has been to remove non-core 
+packages from the core repo, to assist in this.
+To do that, we have to define clearly what is core and non-core.
+(This will have to be done anyway if we wish to give priority to core 
+packages.)
+I think that this would be a *very* useful discussion in this thread.
+And I'm very willing to actively contribute.  (As you might guess:) )
+I have to admit, I'm a bit surprised at the opposition to my proposals 
+by many (but not all) packagers.
+>
+> Users do not differentiate between main/contrib, there's a package
+> they install it, I don't think they look from which repo it comes
+> from.
+
+With this I disagree.  Not only due to my own habit to leave contrib 
+disabled most of the time.  And activate it only to find packages not in 
+main.  (Often after searching elsewhere - but being a programmer, I'm 
+used to compiling/ extra configuring if necessary.)
+Many users have expressed on this list a preference to install packages 
+from main, rather than contrib.
+On the other hand, it is true that many users don't care.
+>
+>>>> Rather that one package was updated, and an optional installed module
+>>>> was not.
+>>>> The fact that the module is optional is the key point.
+>>>> The installer should be flexible enough to give a warning in this case,
+>>>> and ask if you wish to continue the installation.
+>>>
+>>> So basically, you want a --nodeps ?
+>>> If there is a requires, there is usually a good reason. Engineering is
+>>> not randomly adding line to a file until it work.
+>>
+>> How about better configured spec files ?
+>> A better definition (in general) of core packages ?
+>> A focus on ensuring that core packages are maintained ?
+>> Basically my idea behind a core sandbox.
+>> But if you have a better idea ...
+>
+> Again, give us an example of a spec file that needs "better"
+> configuration, otherwise you're theorising.
+
+(Firstly, of course I'm theorising.  And so are those that propose 
+eliminating a separate core set of repos.  But you could argue that it 
+wasn't clear.)
+Sorry, I thought my point was obvious in the context.
+If a package is optional, the spec file contents should never block the 
+upgrade of the package to which it is an option.
+(Which is not necessarily the case if the package is one of several 
+required alternatives.)
+It might be useful to warn the user that the optional module might not 
+work, but to refuse to update the main package just creates an 
+unnecessary blockage.
+>
+>> Just remember, eliminating a supported core breaks the sandbox.
+>> So removing repositories does have secondary effects.
+>> And they should be seriously considered and discussed by those proposing to
+>> remove the repositories.
+>>
+>>>> As well, in the case of Thunderbird, it is almost certain that the
+>>>> installed module was in fact compatible with newer version of
+>>>> Thunderbird.  (A security problem may directly impact Thunderbird or the
+>>>> module, but highly unlikely both packages.)
+>>>> Rpm tags should have been set so that Thunderbird would recognize that
+>>>> the module was appropriate in the newer version.
+>>>
+>>> No. If there is stricter dependency, it is precisely because there is no
+>>> guarantee of any kind of ABI between thunderbird versions. The same goes
+>>> for firefox.
+>>
+>> Overly restrictive compatibility specification is a very a common error in
+>> Mozilla extension packaging.  (It's mentioned in their development guides.)
+>> But the rpm packager should be knowledgable enough to recognize it.
+>> But such errors do happen.
+>
+> Read above.
+I think that this statement stands on its own.
+(Note that I said *Mozilla* extension packaging.)
+Or read added comments above.
+>
+>>>> So in sum, this was probably only a packaging problem.  Whatever the
+>>>> repository.
+In fact, *necessarily* a packaging *error*, to be totally clear.
+
+>>>
+>>> No. Not at all.
+>>> The problem is linked to the difference of support between main and
+>>> contribs.
+>>
+>> In this case, it is inappropriate packaging.
+>> Other cases could be a difference of support.
+>>
+>> There is no reason that extensions should ever block the upgrade of
+>> Thunderbird, unless when one passes from one major version to another.
+>> In that case, the extension will have to be rewritten, a development
+>> function.
+>> (That has only happened a few times since the beginning of Mozilla.)
+>
+> See above (again).
+
+See above (again)
+Or think about this.  The thai localisation is "required" in Mandriva. 
+Even if one doesn't have any knowledge thai, and thus is totally useless.
+Just as logical as an optional Mozilla module blocking the update of 
+Thunderbird.
+They are both packaging errors.
+>
+>> The essence of our disagreement seems to be how to ensure that core packages
+>> are properly supported.
+>
+> Define "core". For KDE users who want to change GTK themes gtk-chtheme
+> (a very small and really old package) is core (i.e. important). The
+> point is, a package is offered in the repos it should be as supported
+> as possible, main/contrib/non-free doesn't/shouldn't matter.
+
+Earlier in this thread, I defined core as necessary for a typical 
+desktop or server or development installation.  Adding that certain 
+widely useful packages, such as Openoffice/LibreOffice and Firefox could 
+be added, due to their general utility.
+This was to include complete desktops, such as Gnome, KDE, and LXDE.
+
+By this definition, the old GTK theme would probably not be considered 
+core, but that doesn't prevent it from being supported.  I would expect 
+that the majority of non-core packages would be well supported.
+The fact that the theme is important to the individual user is not key :
+The question is more, would problems with it block or significantly 
+impair the user's system ?  Considering that there are a number of 
+widely used alternatives, it would probably be decided to be non-core.
+
+Which brings up another important point.  Exactly what constitutes core 
+and non-core should always be a collective decision.  Meaning that 
+borderline cases are never decided by one individual, and decisions 
+should follow core guidelines.
+
+In general, this definition of core follows ideas proposed on Mandriva 
+cooker recently, although I have long had this view.  I would guess that 
+at least a third of "main", if not more, is non-core.
+
+Examples ?  I have installed (and use) poedit and gtranslator, packages 
+which facilitate translating .po files.  They came from "main".
+In my mind they are non-core, and never should have been in main.
+As although they are used in the development process, they are not 
+central to it, and no other package would depend on them.
+However, collective decisions could say that one of them is core (on the 
+basis of being widely used), and I, as a packager, would follow that.
+
+BTW, although I am interested in starting as a new Mageia packager, I 
+have decades of programming/development experience, with complex 
+systems.  So my comments/suggestions come from considerable experience.
+>
+>> My point is that a sandbox will facilitate proper support.  Which would be
+>> facilitated by keeping the 2 sets of free repositories.  And restricting
+>> what should be considered core.
+>> We both know that Mandriva is moving in that direction.  Evidently
+>> recognising that they weren't restrictive enough in the past.
+>
+> Contrib _is_not_ a sandbox, unless you're implying packagers are using
+> users as lab rats.... which isn't true.
+Earlier in this thread, it was "main" and "core" that I qualified as 
+sandboxes.
+In terms of isolating core packages into a repository on which all 
+packages could depend.
+Obviously, "main" strayed from the concept.
+
+regards
+
+- André
+
+
+