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.
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
urpmi my_software
urmpi --unstable my_software
urpmi --list my_software
urpmi --unstable my_software-0.3
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
Jehan wrote:Conclusion: we could imagine this kind of changes in the package system seen by user commands this way: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
urpmi my_software
could install my_software to the last version available regardless any experimental flag.
- Code: Select all
urmpi --unstable my_software
urpmi --searchmedia 'Core Backports' my_software
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
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.
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.
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.
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.
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)
to people who want a single package updated
3/ allows more feedbacks on widely used packages to have them better tested and faster released
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 ?
It's usually not possible to update a single package, you also need the dependencies.
What does that mean ?
I don't see exactly what you want.
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).
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).
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.
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.
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.
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.
Using the backports repository, the "package manager does not install them but is "aware" of them".
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.
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 ?
PietroTux88 wrote:Mageia can use Cauldron how rolling release equal to Cooker please and we can use MAM package manager new please
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
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
urpmi --auto-update
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
Return to General discussions about Mageia
Users browsing this forum: No registered users and 1 guest