Mageia Rolling Release please

This forum is for general chat between members about Mageia.

Technical questions are supposed to be posted in support forums. Not here !

Re: Mageia Rolling Release please

Postby wobo » Apr 5th, '11, 20:40

[quote="dave"]Mageia will be released every six months or once a year as the next mandriva?[quote]

This is just like the 'rolling release' issue not yet decided. It can not be decided because nobody knows the ressources we will have after the first final. Will there be more people helping in development/packaging or less than now? We will see when we get there.

Hopefully all these points about releases will be remembered when the discussion starts for real.
wobo
---
And a new day will dawn for those who stand long
And the forests will echo with laughter
(Stairway to Heaven, Led Zeppelin)
User avatar
wobo
 
Posts: 1649
Joined: Mar 22nd, '11, 17:13

Re: Mageia Rolling Release please

Postby dave » Apr 5th, '11, 21:44

wobo wrote:
dave wrote:Mageia will be released every six months or once a year as the next mandriva?

This is just like the 'rolling release' issue not yet decided. It can not be decided because nobody knows the ressources we will have after the first final. Will there be more people helping in development/packaging or less than now? We will see when we get there.

Hopefully all these points about releases will be remembered when the discussion starts for real.

I know that talking about these things now is premature but I think discuss on it as soon as possible isn't a bad idea.
I asked if mageia will be released every six months or once a year because mandriva has decided to release a new version once a year and I thought mageia follow this principle. But if everything is possible no problem. At the moment now we're just imagining the future.
dave
 
Posts: 58
Joined: Apr 2nd, '11, 08:41

Re: Mageia Rolling Release please

Postby tallship » Apr 6th, '11, 11:58

PietroTux88 wrote:I want Mageia if possible be Rolling Release please , i want packages updated always every day, fglrx and wicd (network manager),others,kernels,all


Well, I believe there haven't been many commits for wicd over the last year. Mabye somewhere between 7 and 10 in all.

Hope that helps :)

Kindest regards,

Bradley D. Thornton
Manager Network Services
http://NorthTech.Eu
Registered Linux User #190795

- "Ask Bill why the string in [MS-DOS] function 9 is terminated by a dollar sign. Ask him, because he can't answer. Only I know that." - Dr. Gary Kildall.
User avatar
tallship
 
Posts: 14
Joined: Apr 6th, '11, 10:35
Location: On the Beaches of Super Sunny Southern California USA

Re: Mageia Rolling Release please

Postby Jehan » Apr 17th, '11, 09:19

Hi,

I would be really interested by a rolling release system.

But from what I read here, it seems many people associate essentially rolling release to "test" or "development". That's because freezing release system (like former Mandriva) gave us this biased vision, with their usual experimental/development package repository (cooker) where everything is up to date to very experimental versions.
This system is indeed definitely unstable. And if you want this kind of release, of course that's bad! Some here seems to think that 2 repositories can be proposed: one "freezed" (except for security fixes of course) and one "experimental" (cooker like). So you have the "choice" and everyone is happy. Or are we? This choice is not the right one because this is a "all or nothing": all very recent (but higher probability of breaking things) or all freezed to "antique" versions (usually more stable).
Of course, you could try and swap from one repository to another when needed, but that's just annoying (and error-prone).

I don't know how it works in Arch but that's not at all the kind of design in Gentoo.
In Gentoo, rolling does not mean at all this all-or-nothing philosophy. I would say actually that a well-thought rolling design is much more stable than a freezed release system, because it allows to get better and more feedback without forcing people to experiment.

In gentoo, one essentially have a single package repository. There is no concept of a experimental/stable repository. Instead the concept is reported on each package. So the "experimental" flags are targeted: one package in the repository typically exists in several version. Usually there is one (or several) "stable" and "experimental" versions. By default you only get the stable version. No mistake is possible. You just can't upgrade by mistake to an experimental package (unless you have specifically configured your system to not care at all about the experimental flag, which is a bad idea, but that's what was cooker). Yet if you want, you can always try to install a newer version. This is a per-package choice. Not a system wide choice.

So the advantages:
1/ extremely stable. You are "always" on a stable configuration. You don't have to choose to make your whole system in danger because you wanted a few software to the latest version.
2/ still always easy possibility to get later software on case-by-case procedure. So nice for end users.
3/ Extremely better test system for package. You don't "have to" test very fast all the packages to their new version the faster possible before the next release.
Really those who think that Ubuntu/Mandriva or these kind of freezed releases have stable repositories are fooling themselves. How many broken packages have I seen in my life! Compared to this, the Gentoo package system is so more subtle and safe!
So instead of testing everything in a very limited time because you MUST release in X days, what do you do in a real rolling system? You test packages as they come:
* they come early? You can put them earlier in the system as "experimental". It means that nobody unaware ("common" user) will install it. But people who "need" it will be able to install it in one click/command line. So you get more testers because the system is easier, makes people want to test, but on a "decision" and only for the softwares they really want.
* They come late? No problem, a rolling system is not anymore pressured by time. Some new package versions won't make it for the next pressed CD. So what? It does not matter. The package will be tested live and available later without having to wait for 6 months.
4/ It is REALLY stable. Yes I insist on stability.
On Gentoo if you were to look on individual packages, one would notice the following strange pattern: you have many packages very early in stable compared to freezing distributions, BUT you also have a lot of other packages much "older" staying in "experimental". Why?
The point is that with such a system, you may have some software tested very fastly by a huge amount of users. So look at a Firefox release: it will be available immediately with an experimental flag, but easy to install if you force it. Many people will do so. So there will be a huge amount of testers and it will pass pretty fast, maybe after a month, to a stable state (if the release is actually stable).
Now let's look some "unknown" package that nearly none uses. It will go to experimental pretty fast as well. And it will probably stay there for quite a long time. But that's ok, it is still there and easy to install, though common users are protected and none will install it by mistake (and break their system).

So let's look now these 2 cases in any freezing distribution: both packages (the famous firefox and the unknown software) will be just treated the same (badly). Just a couple of package testers will test them. If they are released a long time before the distrib release, then users will have to wait a long time. If they are released very shortly at the opposite, they will simply be barely tested and inserted into the workflow. And in the end, both will be released, even the unknown package that is in fact not really tested and maybe highly unstable. Why is it released? Because Free Softwares obviously don't do discrimination and propose any software in the mainstream repository, whether it is famous or not. And this is GOOD. But that does not remove the facts: one is highly tested by thousands of users, the other one has maybe a couple of users which went through just a few features... The freezing design has no granularity and not to make any discrimination will flag anything stable after some time whether it really is or not. The rolling design allows to insert any package into the mainstream flow immediately (no discrimination as well) but leave something unstable as such as long as this is a reality (and there is no shame on it. I have such a library flagged that way in Gentoo for instance, and I am perfectly happy it is in Gentoo and well aware it may not be flagged stable before long... because it is indeed in early versions so it is actually unstable!).

Saying "rolling is unstable" is really not understanding how it works. It is actually SO MUCH MORE STABLE.
We just need an "intelligent rolling" design like in Gentoo. It implies package granularity rolling, multiple version handling in a single repository, a flag system and finally a procedure to promote packages from unstable to stable.

Conclusion: we could imagine this kind of changes in the package system seen by user commands this way:
Code: Select all
urpmi my_software
will install my_software to any latest stable version (if there is any, any recent software could be accepted but set in unstable ONLY if necessary).
Code: Select all
urmpi --unstable my_software
could install my_software to the last version available regardless any experimental flag.
Code: Select all
urpmi --list my_software
could list all versions and their flags.
Code: Select all
urpmi --unstable my_software-0.3
could install a specific version (and we specify --unstable if this version is flagged) regardless the fact there may be more recent version. This can be useful to be able to downgrade a package for instance or test a specific version.

I am not a Mageia developer right now but this kind of problematic does interest me. And as I keep a close eye on Mageia development for potentially migrating to it in the future, and as I would love to finally have a good rolling system as in Gentoo in any of the binary system I use, I would be willing to look into the code of the current rpm package system we use and see how we could modify it to be rolling this way. And maybe develop it.
But as I have several projects on my own on the side, I would prefer the approbation of users that they indeed would be interested (because this kind of system has far less use if the mainstream system does not want to use it obviously) before starting and maybe wasting my code...
Would you be interested?
Jehan
 
Posts: 11
Joined: Apr 10th, '11, 22:08

Re: Mageia Rolling Release please

Postby PietroTux88 » Apr 17th, '11, 10:14

tallship wrote:
PietroTux88 wrote:I want Mageia if possible be Rolling Release please , i want packages updated always every day, fglrx and wicd (network manager),others,kernels,all


Well, I believe there haven't been many commits for wicd over the last year. Mabye somewhere between 7 and 10 in all.

Hope that helps :)

Kindest regards,

Bradley D. Thornton
Manager Network Services
http://NorthTech.Eu


yeah this is good rolling updates every day is good for many people like rolling mirrors and normal mirrors stable and unstable mirrors this is maybe be good mageia
Eat a piece of bread and after you're gone suddenly become a skeleton
User avatar
PietroTux88
 
Posts: 202
Joined: Mar 31st, '11, 09:43

Re: Mageia Rolling Release please

Postby boklm » Apr 17th, '11, 11:53

Jehan wrote:Conclusion: we could imagine this kind of changes in the package system seen by user commands this way:
Code: Select all
urpmi my_software
will install my_software to any latest stable version (if there is any, any recent software could be accepted but set in unstable ONLY if necessary).
Code: Select all
urmpi --unstable my_software
could install my_software to the last version available regardless any experimental flag.

The thing you describe here already exists, and has been in Mandriva for a long time, it's called the backports repositories.
You can easily install packages from backports media using
Code: Select all
urpmi --searchmedia 'Core Backports' my_software
boklm
 
Posts: 44
Joined: Mar 15th, '11, 01:31
Location: Paris

Re: Mageia Rolling Release please

Postby Jehan » Apr 17th, '11, 14:43

boklm wrote:The thing you describe here already exists, and has been in Mandriva for a long time, it's called the backports repositories.
You can easily install packages from backports media using
Code: Select all
urpmi --searchmedia 'Core Backports' my_software


I see. I am looking some information about logics of a package life (I found the Mandriva policy, I guess for now Mageia has the same, or similar at least).

What bothers me with this way of working is that it is not straightforward. As a very simple user who I was when I was using Mandriva, after reading your answer, I had to look for information of what meant a "backport", a "media", the "core" in Mandriva/Mageia environment (note that I have not found what is "Core". There does not seem to be any package type/section named "Core"). So it means to use this tool, you have to understand how works internally the repositories like they explain on the previous link. One cannot say that --searchmedia 'Core Backports' is as obvious as --unstable (or other similar named option). Some abstraction needs to be done.
As a proof, the Mandriva wiki I linked describe this as an "advanced use". In Gentoo, this is the first thing you learn. This is not an "advanced use", this is the core of Portage (the Gentoo package manager). Even the most basic Gentoo user uses this.

What does a user want? He installs a software. Then he sees he does not have the last one. So he would like to know if there is an earlier version. So he lists them (all "media" mixed). Then he choose which one to install. He does not want and care whether the software is in "main", "contrib", "non-free", then in which repository out of 4 is it? He would first have to understand what each means! In other words, the user does not want to know how we are organized, only if the package exists and is considered stable/unstable.

Also what backport seems to mean is that it is out of the "testing" procedure as it is not meant to be inserted into mainstream any time soon (not before next release). Am I right? That's just a convenience "better than nothing" repository.
And finally any package which goes to the mainstream is meant to makes its way to "release" at some point, without any difference from a really stable package and an unstable one. If I have begun a software 2 months ago and it is in version 0.1, I don't see any reason why it would be in "release". But I don't see any reason either why it would not be "somewhere". The system miss some of "unstable release" state. The truth is that if you look into Mandriva repository (from what I remember), you see thousands of package, some are crashing at start after installation, or are at early development state and barely without any feature other than a Proof of Concept. When I was searching for a software, I had to test them one by one because the system does not give me useful information. Then I think "what a mess!".

As a conclusion, it seems that's a very different philosophy from a flag system: I am talking about an stable/unstable state of a package, you tell me about the package flow procedure.
I think something can be constructed above this structure to make it more usable as a core feature. More sane, more safe and more powerful. And to be sure I am understood: I don't mean to do like Gentoo. The logics can be adapted to Mageia, improved, diverged. No system is perfect. I only cite Gentoo because it is simply the only and first system package I ever encountered which made sense (I don't know all of them though: I only know the rpm, apt-get variants, and Portage, so maybe there is even better somewhere!).
Jehan
 
Posts: 11
Joined: Apr 10th, '11, 22:08

Re: Mageia Rolling Release please

Postby boklm » Apr 17th, '11, 16:09

Jehan wrote:As a proof, the Mandriva wiki I linked describe this as an "advanced use". In Gentoo, this is the first thing you learn. This is not an "advanced use", this is the core of Portage (the Gentoo package manager). Even the most basic Gentoo user uses this.

Maybe that's because Gentoo is a distribution for advanced users. On Mageia installing packages from backports repositories is an "advanced use". Regular users do not care about having the very latest version of each software, they just want to have something that works. That's why it's recommended for them to only use the packages from release and updates repositories, it's working, it's tested (or at least it should), it's updated in case of security issue. Advanced users can install backports if they need newer versions of some software, but should be careful about what they are installing, know how to revert in case problem, know that there can be security issues, that it can break something else, etc ... it's not for simple users that just want it to work without having to think about it.
boklm
 
Posts: 44
Joined: Mar 15th, '11, 01:31
Location: Paris

Re: Mageia Rolling Release please

Postby Jehan » Apr 17th, '11, 16:35

Hi,

boklm wrote:Maybe that's because Gentoo is a distribution for advanced users. On Mageia installing packages from backports repositories is an "advanced use". Regular users do not care about having the very latest version of each software, they just want to have something that works. That's why it's recommended for them to only use the packages from release and updates repositories, it's working, it's tested (or at least it should), it's updated in case of security issue. Advanced users can install backports if they need newer versions of some software, but should be careful about what they are installing, know how to revert in case problem, know that there can be security issues, that it can break something else, etc ... it's not for simple users that just want it to work without having to think about it.


I don't agree and that's the topic of this thread (under the theme "rolling or freezed release?", I think the question is actually: what is the best system to provide updates): common users like at the opposite the latest version. Maybe not the very basic user, who just goes on Internet for Facebook and does not care (nor even know) which browser one uses (IE6? "I don't know, that's just written Internet!"). But the slightly-more-aware common user (yet we cannot say he is advanced at all) who wants the last Firefox because he read an article about how better it is than the previous one.

I would even say that's even more these common users who want this kind of feature than advanced users because historic FOSS users have been used to wait for "stability" of a package while common users new in the Free Software world just want everything now! And they are annoyed by this aspect of most distribution.
Moreover I think this new approach on packaging is not a bad thing and we could really improve from our current basis, by having more updates and in same time more stability.
Jehan
 
Posts: 11
Joined: Apr 10th, '11, 22:08

Re: Mageia Rolling Release please

Postby boklm » Apr 17th, '11, 16:39

Jehan wrote:Moreover I think this new approach on packaging is not a bad thing and we could really improve from our current basis, by having more updates and in same time more stability.

What "new approach" ? And I don't see how more updates would bring more stability. It's usually the opposite, more updates means more breakages.
boklm
 
Posts: 44
Joined: Mar 15th, '11, 01:31
Location: Paris

Re: Mageia Rolling Release please

Postby Jehan » Apr 17th, '11, 17:05

Hi,

boklm wrote:
Jehan wrote:Moreover I think this new approach on packaging is not a bad thing and we could really improve from our current basis, by having more updates and in same time more stability.

What "new approach" ? And I don't see how more updates would bring more stability. It's usually the opposite, more updates means more breakages.


"new approach" relative to the current Mandriva/Mageia approach (not relative to the world of package management).

And that's what I was saying in my very first message: that's the typical view on "rolling" release when one think it simply means updating as soon as they are released; opposite to current freezing approach "waiting every 6 months" (or whatever time is chosen) then "breaking" everything at once with barely tested packages.

I propose to make new updates accessible immediately but with an intermediate status. So that 1/ does not break systems for people who install only stable packages 2/ make package more accessible (and that's different from the --searchmedia) to people who want a single package updated 3/ allows more feedbacks on widely used packages to have them better tested and faster released 4/ leaves very unstable experimental package into the unstable state as long as they are so (which may mean forever).
I think that's far more safe and sane that both "wild rolling" (cooker) and freezing release systems.
Jehan
 
Posts: 11
Joined: Apr 10th, '11, 22:08

Re: Mageia Rolling Release please

Postby boklm » Apr 17th, '11, 17:28

Jehan wrote:I propose to make new updates accessible immediately but with an intermediate status. So that 1/ does not break systems for people who install only stable packages 2/ make package more accessible (and that's different from the --searchmedia)

How is that different from --searchmedia ?

to people who want a single package updated


It's usually not possible to update a single package, you also need the dependencies.

3/ allows more feedbacks on widely used packages to have them better tested and faster released

What does that mean ?

I don't see exactly what you want.
boklm
 
Posts: 44
Joined: Mar 15th, '11, 01:31
Location: Paris

Re: Mageia Rolling Release please

Postby Jehan » Apr 17th, '11, 18:28

boklm wrote:
Jehan wrote:I propose to make new updates accessible immediately but with an intermediate status. So that 1/ does not break systems for people who install only stable packages 2/ make package more accessible (and that's different from the --searchmedia)

How is that different from --searchmedia ?


Because --searchmedia works on the understanding on package management internal and Mageia testing procedure => ok, so my package, is it Free or not (non-free)? And then is it officially maintained by Mageia (main or contrib)? Once you guessed this, you have to wonder: will it be in testing or in backports? That may seem easy for you but for many people, it won't be (actually even for me, in particular knowing the section: how do you know a package is officially maintained? And sometimes some Free softwares will be in non-free for some obscure — to most of us — copyright or patent reason or because of a specific strict country law).

It is not a simple model. As a user, I want just to know that a package is considered stable or not.
That's the first reason.

The second is a policy reason. Currently we consider stable any package which is "working" somehow, so they make its way to "release" or "update". But really from what I remember, it means that we find some software version 0.1 and you run it, it's barely usable and crashes all the time.
It does not mean that the software won't become great. There is no criticism against the developers. Simply early development software are not stable, that's all. No shame on it. And that's an independent meaning to "testing".
testing means: yeah the «package» has been tested. It installs well, and you can run the software.
unstable means: the «package» is not sufficiently tested OR this «program» is not stable (the package may have been tested or not, it is independent).

So no, that's another layer of selection. This is usability abstraction (the user does not care about internal policy, but about the results of this policy).

It's usually not possible to update a single package, you also need the dependencies.


Yes so when you authorize a specific software as unstable, either the dependency can be taken from the stable versions, or if the unstable software needs absolutely some specific dependency which is itself unstable, it will ask you if you want to update this as well. That should be a secure and flexible system.
This is what I said about the fact that the "all rolling or all freezed" system is not safe. You need flexibility and safety. Only such a rolling system which is aware of itself can do this ("testing" is not aware of itself. It does not know that what it proposes is testing pkgs. It works the same as the "release" repository).

What does that mean ?

I don't see exactly what you want.


Ok. An unstable software is NOT on another repository that you have to specifically check, then if you forget to uncheck it, it will intrude in your whole system (and possibly break it) by proposing to upgrade anything.
No unstable package are always there. There are simply hidden by a flag. So your package manager does not install them but is "aware" of them.

So let's say you get Firefox 4.0 in the current system. What do you do? You put it in "testing" repository.
Common users won't install it because they don't activate "testing" (fortunately!). So they are frustrated. People on "testing" are mostly developers, packagers, and some very motivated users. That's quite some people probably but that's not a huge mass of testers.

Now on a rolling system, you get Firefox 4.0. You put it in "release" but flagged "unstable". For basic users, that's the same, they will never see it and their system stays safe. But the common "aware" user will go in rpmdrake and see for instance a small tab on the Firefox item labeled "unstable releases available". He really wants Firefox because he read this great article about it! So he click the tab, read the explanation, then click "install" the latest release (getting appropriate warning, and if ever it triggers another unstable dependency, the user is asked to accept or not).
Note the nuance compared to enabling cooker: it does not just melt in the package list. If you enable testing repositories, you would see all testing package in your list without any warning about the provenance. Here an unstable package is always visible, but stays unstable.
So in the end, you have more users testing, but they are kept safe (asked to confirm pkg by pkg, not to allow any testing pkg) and aware of the situation.
Jehan
 
Posts: 11
Joined: Apr 10th, '11, 22:08

Re: Mageia Rolling Release please

Postby boklm » Apr 17th, '11, 19:03

Jehan wrote:Because --searchmedia works on the understanding on package management internal and Mageia testing procedure => ok, so my package, is it Free or not (non-free)? And then is it officially maintained by Mageia (main or contrib)? Once you guessed this, you have to wonder: will it be in testing or in backports? That may seem easy for you but for many people, it won't be (actually even for me, in particular knowing the section: how do you know a package is officially maintained? And sometimes some Free softwares will be in non-free for some obscure — to most of us — copyright or patent reason or because of a specific strict country law).

There is no main/contrib repositories in Mageia, everything is in core. And if you don't care if the software is in core or non-free, you can put both in --searchmedia.

It is not a simple model. As a user, I want just to know that a package is considered stable or not.
That's the first reason.

The second is a policy reason. Currently we consider stable any package which is "working" somehow, so they make its way to "release" or "update". But really from what I remember, it means that we find some software version 0.1 and you run it, it's barely usable and crashes all the time.
It does not mean that the software won't become great. There is no criticism against the developers. Simply early development software are not stable, that's all. No shame on it. And that's an independent meaning to "testing".
testing means: yeah the «package» has been tested. It installs well, and you can run the software.
unstable means: the «package» is not sufficiently tested OR this «program» is not stable (the package may have been tested or not, it is independent).

So no, that's another layer of selection. This is usability abstraction (the user does not care about internal policy, but about the results of this policy).


stable or unstable doesn't mean anything for a single software. For instance you can take a Mandriva 2010.1 package that is "stable", install it on 2009.1 and have something that doesn't work.

Yes so when you authorize a specific software as unstable, either the dependency can be taken from the stable versions, or if the unstable software needs absolutely some specific dependency which is itself unstable, it will ask you if you want to update this as well. That should be a secure and flexible system.

That's exactly what is done when installing a package from the backports repository.
But that's not a "secure system". When people see a list of packages to install, they will click "yes" without checking anything. And seeing a list of packages to update doesn't tell you if something will be broken after the update.

Ok. An unstable software is NOT on another repository that you have to specifically check, then if you forget to uncheck it, it will intrude in your whole system (and possibly break it) by proposing to upgrade anything.
No unstable package are always there. There are simply hidden by a flag. So your package manager does not install them but is "aware" of them.

Using the backports repository, the "package manager does not install them but is "aware" of them".
boklm
 
Posts: 44
Joined: Mar 15th, '11, 01:31
Location: Paris

Re: Mageia Rolling Release please

Postby Jehan » Apr 17th, '11, 19:42

boklm wrote:There is no main/contrib repositories in Mageia, everything is in core. And if you don't care if the software is in core or non-free, you can put both in --searchmedia.


You miss my point. You still have to specify core/non-free and testing/backports. They have an organizational meaning on Mageia procedure. Not a end-user meaning. That's for packager and developer to know, not for the user.

stable or unstable doesn't mean anything for a single software. For instance you can take a Mandriva 2010.1 package that is "stable", install it on 2009.1 and have something that doesn't work.


Of course "stable" has not an absolute meaning. It is still somewhat subjective according to testers. Someone may say some software is stable, regardless a few minor bug whereas the next guy might say these bugs are not minor at all. That's all a matter of choice, just as "testing" (on another level). Once again, I think you miss my point.

And for your example about installing the same package on Mandriva 2010.1 and 2009.1, once again you miss the point. You remain on the "release idea" where a package might be dependent on some prerequisite of a global system. But in a rolling release, you don't care about the release (that's the whole point), only about all dependencies, release-independent. If you have a broken package, it only means the package has a bug (error in the dependency rules). This is not about a release number of the whole system.
That's just about making packages more detailed on dependencies, hence more robust.

Yes so when you authorize a specific software as unstable, either the dependency can be taken from the stable versions, or if the unstable software needs absolutely some specific dependency which is itself unstable, it will ask you if you want to update this as well. That should be a secure and flexible system.

That's exactly what is done when installing a package from the backports repository.
But that's not a "secure system". When people see a list of packages to install, they will click "yes" without checking anything. And seeing a list of packages to update doesn't tell you if something will be broken after the update.


Does the package manager tell the user that it has a list of packages to install or does it tell them that it has a list of software which are "unstable" to install? That's really different. And that's what I called "aware". You are aware on the state of each package. It is not just another list of packages to add to the first one (which I call "non-aware". You are not aware of what you propose, you just propose a list of packages whatever their state/provenance).

Using the backports repository, the "package manager does not install them but is "aware" of them".


Same as above: is he aware they are "backports" package and give according warnings to the user? Or he is aware of them exactly the same way as of any other package in any other repository?
Jehan
 
Posts: 11
Joined: Apr 10th, '11, 22:08

Re: Mageia Rolling Release please

Postby stormi » Apr 17th, '11, 21:54

@Jehan :

I'm not against rolling-releases, if done well, but I think it requires resources we currently don't have to do it well. One interesting approach is that of OpenSuse's project tumbleweed, which provides a rolling-release distribution side by side with a classical distribution with stable releases. Maybe a similar experiment in Mageia (when we have enough resources) could be interesting to check feasibility.

However, let's suppose we keep the current release model at Mageia, inherited from Mandriva but with some changes (no more main/contrib separation, backport_testing media to allow to test new versions of software before they are considered stable enough to reach the backports media).

The main problem you are raising is not related to whether we have a rolling release model or a more classical model with backports. I agree that many users don't care (or care but don't know) about the repository structure. This is a matter of how we present it to the user and how we manage to abstract the repository structure at the user level. Boklm's answers reveal that he knows the internals too much to see at first sight that it's far from obvious for users (no offense intended, boklm :))

Currently (or rather, when Mageia 1 will have been released), one package can exist in 4 versions (in fact, 5, but from the user's point of view it can be reduced to 4, and much users will only see 2 of them), which is already not bad :
- the stable one, which gets security updates and bugfixes. This is what you will use on a production environment
- (for testers) an update candidate that can replace the previous one once it has been tested
- a newer version (aka backport), which works and should have been tested, but with less guarantees than the stable version
- (for testers) a newer testing version that can replace the previous one once it has been tested

We could already improve the user experience regarding package management without changing the repository structure and with tools revolving around the above 4 concepts (stable / update candidate / backport / backport candidate). I'm trying something in this regard (still far from perfect) with mageia-app-db. Concerning the flags you propose for urpmi, they could be implemented while keeping the current release model. Maybe not exactly as you propose but following the same spirit. They would be more "high-level" than the --search-media option and require no knowledge of the actual media behind.

A second problem is that the availability of newer versions for popular software is not always known to the users. We can find ways to improve this by giving more visibility to the backports. Users will for example be able to use mageia-app-db to receive e-mail notifications when their preferred software is available in a newer version, or, if they want to help by testing, be notified that a new test version is available.

If you are curious about this project, see the links in my signature. In particular, if we achieve the goals described in http://mageia-app-db.tuxette.fr/project ... ionalities, couldn't it solve parts of the problems you mention ? This would not solve everything, but would already improve much upon what we have from the user point of view, woudn't it ?
Samuel V.
mageia-app-db : Project site, try it !
stormi
 
Posts: 47
Joined: Mar 29th, '11, 15:54
Location: Lyon

Re: Mageia Rolling Release please

Postby PietroTux88 » Apr 18th, '11, 10:48

yes right if possible have 4 mirros on mageia to choose if have rolling updates

1) stable and updates with bugfix
2)testing or unstable tested softwares
3)unstable and tested with bugfix not correct
4)unstable with many bugs
Eat a piece of bread and after you're gone suddenly become a skeleton
User avatar
PietroTux88
 
Posts: 202
Joined: Mar 31st, '11, 09:43

Re: Mageia Rolling Release please

Postby Jehan » Apr 18th, '11, 21:06

stormi wrote:@Jehan :

I'm not against rolling-releases, if done well, but I think it requires resources we currently don't have to do it well. One interesting approach is that of OpenSuse's project tumbleweed, which provides a rolling-release distribution side by side with a classical distribution with stable releases. Maybe a similar experiment in Mageia (when we have enough resources) could be interesting to check feasibility.


Agreed. It makes sense and when I entered this discussion, I perfectly understood that the release logics choice was not done yet and if ever a rolling release was to be done some time in the future, it would not be for now, but after the first release. I was not asking for Mageia to pass to a rolling release right now. :-)

As for resources, I am a traveler, so the main resources I can provide are development time (if needed because I have also other projects and jobs on my side. But if my time is required for me to have the best distro ever, then it is worth it).

However, let's suppose we keep the current release model at Mageia, inherited from Mandriva but with some changes (no more main/contrib separation, backport_testing media to allow to test new versions of software before they are considered stable enough to reach the backports media).

The main problem you are raising is not related to whether we have a rolling release model or a more classical model with backports. I agree that many users don't care (or care but don't know) about the repository structure. This is a matter of how we present it to the user and how we manage to abstract the repository structure at the user level. Boklm's answers reveal that he knows the internals too much to see at first sight that it's far from obvious for users (no offense intended, boklm :))


I definitely agree. The main point is not to completely change the internal structure of the package management in Mageia, but to get a better user experience. And obviously possibly making this based on the current internal structure (unchanged or the less possible) is better on short and mid-term (on long term, it "may" make sense to want to change internal logics if the current one is too contrary to the finale philosophy. Otherwise it is better not to change it).

Currently (or rather, when Mageia 1 will have been released), one package can exist in 4 versions (in fact, 5, but from the user's point of view it can be reduced to 4, and much users will only see 2 of them), which is already not bad :
- the stable one, which gets security updates and bugfixes. This is what you will use on a production environment
- (for testers) an update candidate that can replace the previous one once it has been tested
- a newer version (aka backport), which works and should have been tested, but with less guarantees than the stable version
- (for testers) a newer testing version that can replace the previous one once it has been tested

We could already improve the user experience regarding package management without changing the repository structure and with tools revolving around the above 4 concepts (stable / update candidate / backport / backport candidate). I'm trying something in this regard (still far from perfect) with mageia-app-db. Concerning the flags you propose for urpmi, they could be implemented while keeping the current release model. Maybe not exactly as you propose but following the same spirit. They would be more "high-level" than the --search-media option and require no knowledge of the actual media behind.


Ok.

A second problem is that the availability of newer versions for popular software is not always known to the users. We can find ways to improve this by giving more visibility to the backports. Users will for example be able to use mageia-app-db to receive e-mail notifications when their preferred software is available in a newer version, or, if they want to help by testing, be notified that a new test version is available.

If you are curious about this project, see the links in my signature. In particular, if we achieve the goals described in http://mageia-app-db.tuxette.fr/project ... ionalities, couldn't it solve parts of the problems you mention ? This would not solve everything, but would already improve much upon what we have from the user point of view, woudn't it ?


So I have fastly looked at the page. If I understand, that's mainly a project where users could manage packets through a web interface.
Could there not be also an equivalent highly featured package management GUI?
The way I see things, I think the rpmdrake (I have not touched a Mandriva for maybe 1/2 years now, so my knowledge comes from this time. So unless there have been huge improvement since then…) could really be improved to provide more valuable management: flagging packages, having possibility to see and install experimental versions, at the opposite also NOT SHOWING unstable software by default (whether the package is tested or not).

Basically a package management GUI should be both very clean by default, show only stable softwares with non-technical information, hence only valuable information for a end user (I mean, unless the package is technical of course), but in the same time provide access to advanced feature (access unstable or untested package, etc.).

Actually the project your page details could be extended to the GUI, make it "community aware". When you are in the GUI, you could be able to send screenshots, modify, fix or localize a description which will be sent upstream (then it will be either checked for approval or directly modified if the user has an official localizer account for instance). The daily tool to install package could be in the same time a community tool to build a better general experience.
If you know that a software exists in a newer version, you could make a request from the GUI also, vote, and so on (basically all the stuffs you say on your page).

What I mean is that I think we can really gain from making the community tool inside the distribution itself than outside as a web page (but both can co-exist). Because going to the web page, to search for a specific package, modify it, and so on is an active action. So it means it will concern mostly active users willing to participate. But if it is integrated in the tool that users use anyway (the package management GUI), then even passive users will participate: you see an error in a description while you install your file, you edit it and click "update", get a "thanks" message and that's it. You go back to your usual stuffs. No need to be a participative users. When you got to get passive users be key elements in the distribution development, you know you really make the best out of your community.
Your project made me think a lot. Much could be achieved this way, I think.

Anyway thanks for your message. It all made a lot of sense. Now I hope we will be able to find a nice way to improve package management user experience and make it rolling and stable. ;-) Maybe I'll finally find a binary distribution with a very good package management. :-)
Jehan
 
Posts: 11
Joined: Apr 10th, '11, 22:08

Re: Mageia Rolling Release please

Postby PietroTux88 » Apr 20th, '11, 08:38

mandriva has confirm cooker continue to be rolling release

Mandriva 2011 beta2
Posted on April 18, 2011 by Eugeni Dodonov

Hi all,

Despite the last-minute problems discovered last week which resulted in a 1-week delay, Mandriva 2011 beta2 should finally be hitting the mirrors in some hours. Make sure to check the devel/iso/2011 directory on your favorite mirror for the latest .iso images.

As with previous beta release, the images are provided for i586 and x86_64 architectures, and are able to work in both live mode, and can be used for the installation.

For this release, most of the UI and desktop-related features should be integrated, including new login manager functionality, stack folders integration into the environment, new welcome and launcher application, new panel and overall desktop look-and-feel (some details and screenshots could be found on Eugeni’s blog here and here, and also (in russian) here ). It also features new default theme and artwork.

I’d also like to mention that most of those changes were developed by our friends from ROSA Labs, and to thank them once again for their hard work!

Besides the UI and KDE changes, Mandriva 2011 beta2 features LibreOffice 3.3.0, and comes with the latest kernel 2.6.38.3, systemd 24, gcc 4.6.0, besides smaller package versions updates.

Another notable difference is the integration of Anssi Hannula’s reimplementation of kms and graphical drivers interaction (announced initially here and described in details here.

As for the next steps, as previously announced, in few days Mandriva 2011 version will be branched for final stabilization and final packages inclusion, and Mandriva Cooker development will continue as rolling release.

So, thats it for now. Stay tuned for further mdvnews! :)


Mageia can use Cauldron how rolling release equal to Cooker please and we can use MAM package manager new please
Eat a piece of bread and after you're gone suddenly become a skeleton
User avatar
PietroTux88
 
Posts: 202
Joined: Mar 31st, '11, 09:43

Re: Mageia Rolling Release please

Postby teaage » Apr 20th, '11, 11:11

PietroTux88 wrote:Mageia can use Cauldron how rolling release equal to Cooker please and we can use MAM package manager new please


Cauldron will definitely be rolling release, the way Cooker is and was. That's the only model which makes sense for a development environment. :)

TeaAge
User avatar
teaage
 
Posts: 19
Joined: Mar 25th, '11, 16:57

Re: Mageia Rolling Release please

Postby PietroTux88 » Apr 20th, '11, 13:36

teaage wrote:
PietroTux88 wrote:Mageia can use Cauldron how rolling release equal to Cooker please and we can use MAM package manager new please


Cauldron will definitely be rolling release, the way Cooker is and was. That's the only model which makes sense for a development environment. :)

TeaAge


ok where are mirrors for Cauldron i don't see on mageia forum and website please
i want add mirrors for have always Cauldron installed
Eat a piece of bread and after you're gone suddenly become a skeleton
User avatar
PietroTux88
 
Posts: 202
Joined: Mar 31st, '11, 09:43

Re: Mageia Rolling Release please

Postby teaage » Apr 20th, '11, 15:10

Do you have Mageia installed? If so, dou you have repositories configured, so you get updates? Then you have everything you need.
As long as you don't change your repositories you will always stay with cauldron.

Reagrds,
TeaAge
User avatar
teaage
 
Posts: 19
Joined: Mar 25th, '11, 16:57

Re: Mageia Rolling Release please

Postby PietroTux88 » Apr 20th, '11, 15:40

teaage wrote:Do you have Mageia installed? If so, dou you have repositories configured, so you get updates? Then you have everything you need.
As long as you don't change your repositories you will always stay with cauldron.

Reagrds,
TeaAge


thanks you now i understand well, after release mageia 1 i have always repo of beta Cauldron true?mageia always use Cauldron and not how to mandriva cooker or 2010.1,2010.2 ?
Eat a piece of bread and after you're gone suddenly become a skeleton
User avatar
PietroTux88
 
Posts: 202
Joined: Mar 31st, '11, 09:43

Re: Mageia Rolling Release please

Postby teaage » Apr 20th, '11, 16:04

The system in Mandriva and Mageia is the same.
Cooker and Cauldron will always be rolling. Befor each release there will be a feature freeze (just a short time), where no new software versions will be implement (but updates), just to ensure the the stability. At the moment of the release Cauldron will be the same like Mageia 1 (for example). If you don't change your repositories after the release, the developer will bring all the new stuff to cauldron (and so to you).
But IF you change the repos to Mageia 1, you will stick with Mageia 1.

So, for now you have a Cauldron installation. Don't change anything and easly update your system with
Code: Select all
urpmi --auto-update

frequently and you will always have the latest available software for mageia (=> rolling release).

TeaAge
User avatar
teaage
 
Posts: 19
Joined: Mar 25th, '11, 16:57

Re: Mageia Rolling Release please

Postby PietroTux88 » Apr 20th, '11, 16:41

teaage wrote:The system in Mandriva and Mageia is the same.
Cooker and Cauldron will always be rolling. Befor each release there will be a feature freeze (just a short time), where no new software versions will be implement (but updates), just to ensure the the stability. At the moment of the release Cauldron will be the same like Mageia 1 (for example). If you don't change your repositories after the release, the developer will bring all the new stuff to cauldron (and so to you).
But IF you change the repos to Mageia 1, you will stick with Mageia 1.

So, for now you have a Cauldron installation. Don't change anything and easly update your system with
Code: Select all
urpmi --auto-update

frequently and you will always have the latest available software for mageia (=> rolling release).

TeaAge


ok thanks i understand now
Eat a piece of bread and after you're gone suddenly become a skeleton
User avatar
PietroTux88
 
Posts: 202
Joined: Mar 31st, '11, 09:43

PreviousNext

Return to General discussions about Mageia

Who is online

Users browsing this forum: No registered users and 1 guest

cron