| Summary: | sys-apps/baselayout-vserver has been masked, but there is no stable replacement | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gabriel <trenirit> |
| Component: | [OLD] baselayout | Assignee: | Gentoo VPS Team (OBSOLETE) <vserver-devs+disabled> |
| Status: | VERIFIED WONTFIX | ||
| Severity: | major | CC: | gentoo, moixa |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Gabriel
2009-01-11 09:10:41 UTC
(In reply to comment #0) > And the sys-apps/baselayout-vserver has just been masked, unfortunately there > is no stable replacement then use the unstable one (believe me, it is far more stable and usable than baselayout-vserver). nothing else beside openrc is supported by the vserver team > Then I found that sys-apps/baselayout-2 and sys-apps/openrc are still in > testing. i guess it will stay testing for quite a while, and i can do nothing about it > why replacing a stable package by a testing one ? because the unstable baselayout/openrc works far better than the old baselayout-vserver (which is deprecated and unmaintained for ages) > Anyway, I put these two packages into /etc/portage/package.keywords, and tried: > > emerge -pv baselayout > > And it gives me this: > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ] sys-apps/sysvinit-2.86-r10 USE="(-ibm) (-selinux) -static" 101 > kB > [ebuild N ] sys-apps/baselayout-2.0.0 USE="-build" 23 kB > [ebuild N ] sys-apps/openrc-0.4.1-r1 USE="ncurses pam unicode -debug" 142 > kB > [blocks B ] <sys-apps/sysvinit-2.86-r11 ("<sys-apps/sysvinit-2.86-r11" is > blocking sys-apps/openrc-0.4.1-r1) keyword sys-apps/sysvinit-2.86-r11 then > > Total: 3 packages (3 new), Size of downloads: 265 kB > Conflict: 1 block (1 unsatisfied) > > > > Actual Results: > I have now an unbootable system (fortunately a testing one). > > Expected Results: > Could you remove the Masked keyword from sys-apps/baselayout-vserver until > this is fixed and the replacement package are marked as stable? > > Could you remove the Masked keyword from sys-apps/baselayout-vserver until > this is fixed and the replacement package are marked as stable? no. > then use the unstable one (believe me, it is far more stable and usable than > baselayout-vserver). nothing else beside openrc is supported by the vserver > team > > because the unstable baselayout/openrc works far better than the old > baselayout-vserver (which is deprecated and unmaintained for ages) > I might ask what is the purpose of "stable" and "testing" then, but this would not be relevant to the bug I guess. Never mind. > keyword sys-apps/sysvinit-2.86-r11 then Good one, I should have done that from the beginning actually, thanks. How is this acceptable? If the unstable repalcement is in practice more stable than the obsoleted stable package, why not mark it stable? And if the stable package being obsoleted has no stable replacement, and it is necessary for many users (and it is), shouldn't that be reason enough not to obsolete it until a replacement is tested and proven stable? I don't mean to be a douchebag, but I am very confused by these actions, and since it affects me directly I must call it out. (In reply to comment #3) > How is this acceptable? If the unstable repalcement is in practice more stable > than the obsoleted stable package, why not mark it stable? because i cannot simply mark baselayout/openrc stable, that decision has to made by the base-system team. (In reply to comment #4) > And if the stable package being obsoleted has no stable replacement, and it is > necessary for many users (and it is), shouldn't that be reason enough not to > obsolete it until a replacement is tested and proven stable? why? the replacement is much better, and just because it doesn't have a stable flag does not mean it is any worse, in fact the opposite is true > I don't mean to > be a douchebag, but I am very confused by these actions, and since it affects > me directly I must call it out. the thing is that baselayout-vserver has not seen any bug fix or improvement for a very long time, but openrc is actively maintained, fixes a lot of hacks that were previously necessary and generally works very good. (In reply to comment #5) > because i cannot simply mark baselayout/openrc stable, that decision has to > made by the base-system team. Fair. (In reply to comment #5) > why? the replacement is much better, and just because it doesn't have a > stable flag does not mean it is any worse, in fact the opposite is true If it is indeed better, and I don't doubt it is, my point is that it should appear so and be available without the stigma of "unstable" to its users. Do you disagree? (In reply to comment #5) > the thing is that baselayout-vserver has not seen any bug fix or > improvement for a very long time, but openrc is actively maintained, fixes a > lot of hacks that were previously necessary and generally works very good. Also a fair point. If true, I do not understand why the public cannot be assured of this by a stable indication of the alternative. If that is not ours to grant, then how do we pound on the doors of those that do have the authority. As it is, the perception is that nothing is stable in this situation, which is what I cannot understand to be acceptable. *** Bug 258054 has been marked as a duplicate of this bug. *** Another remark. If vserver is all you control, why would you mark it for removal without a stable alternative? Do you mean to force users to accept unstable packages based on your opinion of "better"? I won't argue whether the other is actually better or not, and indeed perhaps it is. But it is not marked stable, and people are generally reluctant (with good reason) to accept packages marked unstable. I strongly argue that deprecation of anything marked stable without a replacement marked stable is a mistake. Please reverse this decision until such time. If you feel strongly enough, by all means, demand they stabilize, organize a grass roots effort to lobby them, whatever must be done. But please do not deprecate in favor of that package until they do. This leaves stable-only users out in the cold, despite your (assumedly) altruistic intentions. (In reply to comment #8) > Another remark. If vserver is all you control, why would you mark it for > removal without a stable alternative? Do you mean to force users to accept > unstable packages based on your opinion of "better"? yes > I won't argue whether the > other is actually better or not, and indeed perhaps it is. But it is not > marked stable, and people are generally reluctant (with good reason) to accept > packages marked unstable. i don't see the reason. > I strongly argue that deprecation of anything marked > stable without a replacement marked stable is a mistake. i still don't see it. > Please reverse this > decision until such time. i don't think so > If you feel strongly enough, by all means, demand > they stabilize, organize a grass roots effort to lobby them, whatever must be > done. But please do not deprecate in favor of that package until they do. > This leaves stable-only users out in the cold, despite your (assumedly) > altruistic intentions. vserver was never a stable-only area. Wow. Okay. Thanks for the candor, in any case. The conclusion of this is simple: the current stable package can not be removed before a stable alternative was unmasked. No users should be required to run on testing packages. (The official terms are stable and testing portage tree.) Thanks, Tobias That is the rational conclusion I was seeking. Please adivse how corrective efforts should be implemented and if there is any way in which I can help. (In reply to comment #11) > No users should be required to run on testing packages. says who? (In reply to comment #13) > (In reply to comment #11) > > No users should be required to run on testing packages. > > says who? > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3 "We recommend that you only use the stable branch. However, if you don't care about stability this much [..]" The testing branch/flags is for TESTING and that's not what I want to use my server for. Regards, T. well, i recommend to use openrc regardless of it's keywords. That's perfectly fine with me, but does not help resolving this bug. I suggest to postpone the removal until all the required packages for the migration were marked stable. This would then also reflect the state of the openvc migration documentation. No developer in vserver herd is interested in sys-apps/baselayout-vserver package. This means that this package is unmaintained. Such packages are to be removed from the tree (no matter stable they are or unstable). At this point of time we don't want users to feel safe using sys-apps/baselayout-vserver that's why it's hard masked. So if you already use baselayout-vserver just unmask it and be happy, if you are doing new install, use openrc. Benedikt I think we should not remove this package in 30 days. Let's remove it when openrc be marked stable but keep hardmasked until then. Now, everybody please stop complaining. If you really have some free time better spend it better on fixing existing bugs. (In reply to comment #17) > Benedikt I think we should not remove this package in 30 days. Let's remove it > when openrc be marked stable but keep hardmasked until then. yes, that would be a good idea, i think the 30 days are over now anyway, and i did not plan to remove it :) > Now, everybody please stop complaining. If you really have some free time > better spend it better on fixing existing bugs. yes, and remember to not take KEYWORDS too seriously, we're not debian, so mixing packages is easy-peasy. So... I have a virtual vpslink server hosted in the US that appears to have the problem documented here. I can't see, other than the discussion, a recommended course of action to get round this bug. Can someone provide instructions? (In reply to comment #19) > I can't see, other than the discussion, a recommended course of action to get > round this bug. Can someone provide instructions? unmask sys-apps/baselayout-vserver if you want to keep everything as it is, or if you want to upgrade to openrc the current list of packages that need to be keyworded is: =sys-apps/openrc-0.4.3-r1 ~$[target/arch] ~sys-apps/baselayout-2.0.0 ~$[target/arch] ~sys-fs/udev-133 ~$[target/arch] =sys-apps/sysvinit-2.86-r12 ~$[target/arch] (In reply to comment #20) > (In reply to comment #19) > > I can't see, other than the discussion, a recommended course of action to get > > round this bug. Can someone provide instructions? > > unmask sys-apps/baselayout-vserver if you want to keep everything as it is, or > if you want to upgrade to openrc the current list of packages that need to be > keyworded is: > > =sys-apps/openrc-0.4.3-r1 ~$[target/arch] > ~sys-apps/baselayout-2.0.0 ~$[target/arch] > ~sys-fs/udev-133 ~$[target/arch] > =sys-apps/sysvinit-2.86-r12 ~$[target/arch] > I had this same problem but solved it by keywording.... sys-apps/sysvinit-2.87-r3 ~amd64 and doing that install allowed my world upgrade to work. just for reference: the currently recommended keyword list: ~sys-apps/baselayout-2.0.1 ~sys-apps/openrc-0.6.0 =sys-apps/sysvinit-2.87-r3 FYI: sys-apps/baselayout-vserver ist now hard-masked for ~2,5 years without a stable alternate. Is there a migration guide to migrate to baselayout/openrc? I found an 5-years old blog post (http://blogs.gentoo.org/hollow/2006/11/03/baselayout_vserver_is_dead/) but i suppose, this is also deprecated. |
