I noticed that openSUSE:Tools has dropped its 11.3 repo already.
I understand 11.3 is EOL'd, but it seems like Tools repo should be special, as it contains zypper -- the tool that lets you upgrade.
I understand that EOL means no longer "community supported" - that's fine.. but it seems to me that "community supported" is a completely different concept than "exists as a repo in a project".
After all, openSUSE:Tools has RHEL 4 and all these other non-SUSE repos... are those distributions "community supported" by the openSUSE project??
So I don't understand the rush to remove the repo.
Needless to say, I still have stable 11.3 systems around that I'm not ready to upgrade just yet...
Thanks, -Archie
On Mon, 23 Jan 2012 20:18:49 -0600, Archie Cobbs wrote:
I understand 11.3 is EOL'd, but it seems like Tools repo should be special, as it contains zypper -- the tool that lets you upgrade.
Arguably, the version of zypper that you've got on your 11.3 box (assuming you've kept it up to date) will be the last version that's available on 11.3, so whether the repo is around or not doesn't seem particularly important, because the repo wouldn't be updated anyways.
But you might check on some of the archive repo sites (like gwdg.de) and see if it's there.
Jim
Am Montag, 23. Januar 2012, 20:18:49 schrieb Archie Cobbs:
I noticed that openSUSE:Tools has dropped its 11.3 repo already.
I understand 11.3 is EOL'd, but it seems like Tools repo should be special, as it contains zypper -- the tool that lets you upgrade.
No, it was never part of that repo.
I understand that EOL means no longer "community supported" - that's fine.. but it seems to me that "community supported" is a completely different concept than "exists as a repo in a project".
After all, openSUSE:Tools has RHEL 4 and all these other non-SUSE repos... are those distributions "community supported" by the openSUSE project??
So I don't understand the rush to remove the repo.
Needless to say, I still have stable 11.3 systems around that I'm not ready to upgrade just yet...
Thanks, -Archie
OK forget zypper and openSUSE:Tools for the moment...
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
Do others not agree?
-Archie
On Tue, Jan 24, 2012 at 3:27 AM, Adrian Schröter adrian@suse.de wrote:
Am Montag, 23. Januar 2012, 20:18:49 schrieb Archie Cobbs:
I noticed that openSUSE:Tools has dropped its 11.3 repo already.
I understand 11.3 is EOL'd, but it seems like Tools repo should be special, as it contains zypper -- the tool that lets you upgrade.
No, it was never part of that repo.
I understand that EOL means no longer "community supported" - that's fine.. but it seems to me that "community supported" is a completely different concept than "exists as a repo in a project".
After all, openSUSE:Tools has RHEL 4 and all these other non-SUSE repos... are those distributions "community supported" by the openSUSE project??
So I don't understand the rush to remove the repo.
Needless to say, I still have stable 11.3 systems around that I'm not ready to upgrade just yet...
Thanks, -Archie
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- Archie L. Cobbs
On Tue, 2012-01-24 at 08:13 -0600, Archie Cobbs wrote:
OK forget zypper and openSUSE:Tools for the moment...
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
Do others not agree?
-Archie
I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?
Bryen
On Tue, Jan 24, 2012 at 11:22 AM, Bryen M Yunashko suserocks@bryen.com wrote:
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
Do others not agree?
-Archie
I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?
Not only that, it's sometime not easy to keep the packages building on old distros.
On 1/24/2012 9:25 AM, Claudio Freire wrote:
On Tue, Jan 24, 2012 at 11:22 AM, Bryen M Yunashkosuserocks@bryen.com wrote:
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
Do others not agree?
-Archie
I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?
Not only that, it's sometime not easy to keep the packages building on old distros.
It's difficult but I do it all the way back to 10.0 for most of my stuff and the availability of say the current openssh on production boxes that can't lightly be replaced is worth a lot more than the prettiness of the spec file or the time it took for one guy to produce it. In that particular case it was pretty easy to get openssh building back to 10.2, but I have a problem I may or may not solve that prevents it on 10.1 & 10.0. But 10.2 is pretty good and worth doing. I only have a few 10.0 and 10.1 boxes and a lot more 10.3 and up.
Another scenario is, maybe you can't continue to track the current version of something, but it's still very valuable to have whatever was the last version that _did_ build in that environment.
It's usually far newer than whats' in the oss or updates repo, and often new enough to get you by some other otherwise impasse. For instance, maybe I can't get php5.3 built on 10.1, but maybe 5.2 did build? Well the current codeigiter can use php 5.3 or 5.2 but not 5.1.7 that came with OS 10.1. So if I have a range of boxes in production, including some 10.0 and 10.1, and I want to start working on some new projects and I want the developers to use codeigniter, it means I can actually deploy the current codeigniter everywhere.
If I had been tracking openssh in my home obs project earlier than a few weeks ago, maybe I still wouldn't have the current version on 10.0, but I'd surely have a lot newer version that what my 10.0 and 10.1 boxes are stuck with now. Wherever along the way it stopped being buildable, it was long after the day the 10.0 oss repo was published or even the final update to the updates repo, and I would _love_ to have that package right now.
Having a repo that builds against a given old OS version, and tracks packages as long as it can, and simply stops updating packages once they can no longer be built in that environment, but does not delete those final package versions whatever they were, is very valuable for years afterwards.
On Wed, Jan 25, 2012 at 5:46 AM, Brian K. White brian@aljex.com wrote:
Having a repo that builds against a given old OS version, and tracks packages as long as it can, and simply stops updating packages once they can no longer be built in that environment, but does not delete those final package versions whatever they were, is very valuable for years afterwards.
Good point.
So, you're saying openSUSE:Tools should add DISCONTINUED:openSUSE:11.3.
On 1/25/2012 8:30 AM, Claudio Freire wrote:
On Wed, Jan 25, 2012 at 5:46 AM, Brian K. Whitebrian@aljex.com wrote:
Having a repo that builds against a given old OS version, and tracks packages as long as it can, and simply stops updating packages once they can no longer be built in that environment, but does not delete those final package versions whatever they were, is very valuable for years afterwards.
Good point.
So, you're saying openSUSE:Tools should add DISCONTINUED:openSUSE:11.3.
It would be nice. But it would be nice _for me_ if every repo did that. I _loved_ it when kotd was doing that. But I have to admit it would multiply the space requirements rather a lot and I'd rather have some OBS than no OBS.
It would also not really help very much with some packages if they are already not buildable on 11.3 etc. For instance, package foo might have started out building for os11.3 at foo1.0 when os11.3 came out.
2 years later foo is up to foo3.1 and still builds for 11.3 without problem.
Then foo3.2 comes out and somehow no longer is buildable on 11.3, or at least not without real effort. Maybe it requires newer autoconf or gcc or who knows what...
At that point, in my own obs home repo where the various older targets have already been existing a while, my 11.3 repo has foo3.1 forever, and my 11.4 and above have foo3.2 and newer.
But now that foo has already changed to 3.2, if I were to create my os11.3 repo _today_, I would _not_ be able to have a foo3.1. I would only have the current foo3.2 spec file and src.rpm and they would not build on os11.3 and so I'd have nothing, just the foo1.0 that os11.3 originally shipped with, and even then I'd only have that _if_ os11.3 happened to actually include foo in oss or non-oss.
There is no git/svn-like history of old spec files and src.rpm's you can refer back to. (I would love that!)
So adding the discontinued build targets would be nice yes, but just understand what adding it today will and will not get you.
Some stuff will be buildable with little or no effort, some stuff will be buildable with a little effort, some stuff will be unbuildable or only with more effort than anyone will do. That's some value already.
But at least half of the value only comes from having had it in place already since before that OS version goes EOL when every single package built perfectly, and maintained continuously after that so that as upstream packages and their current spec files go incompatible, at least the last-built binary packages are left behind, and their matching src.rpms which includes the all important spec file, so those binary packages are documented and reproducable also.
On Jan 24, 2012, at 8:22 AM, Bryen M Yunashko suserocks@bryen.com wrote:
On Tue, 2012-01-24 at 08:13 -0600, Archie Cobbs wrote:
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
Do others not agree?
I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?
Longer than (for example) RHEL, which was first released seven years ago... ?
-Archie
Holy crap.
I just realized that OBS has blown away ALL 11.3 repos, including my home directory, not just openSUSE:Tools.
Argggh... trying to remain philosophical here...
We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
So the aforementioned long term stability of openSUSE has just been invalidated as a feature!
The openSUSE community is not just a bunch of Linux kids who all like to live on the bleeding edge. It's used for serious applications all over the place. To some of you folks 11.3 may seem like ancient history but in my world it's chugging along nicely. It's only been out for 18 months for goodness sake!
OK, I can accept that I'm in the minority. So what is the right answer then for me? I guess Tumbleweed is supposed to be the solution to this problem?
In any case, here is one thing I still don't understand: will someone please explain to me why RHEL 4, released 7 years ago, is more important to the openSUSE community than openSUSE 11.3, released 18 months ago?
-Archie
On Tue, Jan 24, 2012 at 1:03 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
On Jan 24, 2012, at 8:22 AM, Bryen M Yunashko suserocks@bryen.com wrote:
On Tue, 2012-01-24 at 08:13 -0600, Archie Cobbs wrote:
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
Do others not agree?
I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?
Longer than (for example) RHEL, which was first released seven years ago... ?
-- Archie L. Cobbs
On Thu, Jan 26, 2012 at 2:47 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
Just add the DISCONTINUED repo to your home, and all is fine.
Just a question... do the DISCONTINUED repos have all updates applied?
* Claudio Freire klaussfreire@gmail.com [01-26-12 13:05]:
On Thu, Jan 26, 2012 at 2:47 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
Just add the DISCONTINUED repo to your home, and all is fine.
Just a question... do the DISCONTINUED repos have all updates applied?
and then your next stop would be "evergreen" which hasn't picked up 11.3 yet.
I am using evergreen repos to maintain my 11.2 server.
On Thu, Jan 26, 2012 at 12:11 PM, Patrick Shanahan paka@opensuse.org wrote:
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
Just add the DISCONTINUED repo to your home, and all is fine.
and then your next stop would be "evergreen" which hasn't picked up 11.3 yet.
Good grief.
The fact that people have already gone to the trouble to create "Evergreen", a valiant but imperfect kludge, speaks for itself.
-Archie
* Archie Cobbs archie.cobbs@gmail.com [01-26-12 13:21]:
On Thu, Jan 26, 2012 at 12:11 PM, Patrick Shanahan paka@opensuse.org wrote:
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
Just add the DISCONTINUED repo to your home, and all is fine.
and then your next stop would be "evergreen" which hasn't picked up 11.3 yet.
Good grief.
The fact that people have already gone to the trouble to create "Evergreen", a valiant but imperfect kludge, speaks for itself.
Not really, you are expecting something that is not provided from a *product that is presented up front as not-a-long-term-solution*, ie: 18 mos
You *did* read the notices about the *supported* life of the product when you chose it for install, so why expect more now?
If you really need long term, you need to use the commercial SuSE offerings, or the adaptations people are graciously maintaining as have been described to you.
The choice is yours as it was when you originally installed.
On Thu, Jan 26, 2012 at 12:04 PM, Claudio Freire klaussfreire@gmail.com wrote:
On Thu, Jan 26, 2012 at 2:47 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
Just add the DISCONTINUED repo to your home, and all is fine.
So that solves the problem for my home repository, but what about the 10-15 other repos that our machines depend on? For example, Apache2:Modules, server:monitoring, etc., etc.
So that doesn't seem like a very scalable solution.
-Archie
-- Archie L. Cobbs
On Thu, Jan 26, 2012 at 3:15 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
So that solves the problem for my home repository, but what about the 10-15 other repos that our machines depend on? For example, Apache2:Modules, server:monitoring, etc., etc.
So that doesn't seem like a very scalable solution.
Ask them to add it?
The point of phasing out repos is to curb unneeded stuff. So, for those projects you depend on, adding the DISCONTINUED repo is like a sign of interest.
I agree with earlier posts, it's an imperfect solution, but it's what we have.
To attempt a justification as to why older RHEL distros still exist, non-opensuse repos get added with less frequency. Otherwise, it wouldn't be possible to keep them all, just as it isn't possible with opensuse ones. You have to draw a line somewhere.
The name change may be a nuisance, but I can't think of a better way to handle it. Otherwise I'd propose it.
On 1/26/2012 1:15 PM, Archie Cobbs wrote:
On Thu, Jan 26, 2012 at 12:04 PM, Claudio Freireklaussfreire@gmail.com wrote:
On Thu, Jan 26, 2012 at 2:47 PM, Archie Cobbsarchie.cobbs@gmail.com wrote:
We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
Just add the DISCONTINUED repo to your home, and all is fine.
So that solves the problem for my home repository, but what about the 10-15 other repos that our machines depend on? For example, Apache2:Modules, server:monitoring, etc., etc.
So that doesn't seem like a very scalable solution.
-Archie
-- Archie L. Cobbs
I agree 100%. I made the mistake of using Server:Monitoring and some others and now I don't do that any more. Anything I really need maintained for myself, I copy to my own home project, which means living without a lot of things I would like to have newer because I can't maintain that much all by myself.
Your comment about the existence of evergreen speaking for itself I also agree completely with.
We who chose suse a few years ago because it had qualities that said "we will be able to count on this for a long time" have now all gotten burned. Suse is changing way too much from month to month, but we're all invested in it now, servers already installed and deployed and 24/7 customers running their entire business on them, many with special EDI setups with other parties requiring non-trivial firewall coordination with customers-of-customers and vendors-of-customers IT people, If an IP changes, it no longer matches the external peoples firewalls and all the EDI transactions break... Uncountable business damage with orders not received or processed, etc, so it's rather non-trivial to upgrade or migrate these customers to other boxes just because the os version went eol a few months later. In place upgrades are out because as difficult as a migration to another newer box is, at least it can be reverted instantly with 100% confidence and safety. Not so with an in-place upgrade.
On Thu, Jan 26, 2012 at 1:06 PM, Brian K. White brian@aljex.com wrote:
I agree 100%. I made the mistake of using Server:Monitoring and some others and now I don't do that any more. Anything I really need maintained for myself, I copy to my own home project, which means living without a lot of things I would like to have newer because I can't maintain that much all by myself.
The supposedly great thing about OBS is that we all get to share common wisdom of how to build and deploy an incredibly wide range of software, no matter who you are or what you are doing, and everyone benefits. This is exactly what open source is all about.
However, the way things are now, anyone who wants to use a stable platform for mission critical services is being forced to NOT share this wisdom.. just read the above quote for example.
I'm surprised the powers that be wish to offend and exclude that group. What a pity.
On Thu, Jan 26, 2012 at 12:28 PM, Claudio Freire klaussfreire@gmail.com wrote:
To attempt a justification as to why older RHEL distros still exist, non-opensuse repos get added with less frequency. Otherwise, it wouldn't be possible to keep them all, just as it isn't possible with opensuse ones. You have to draw a line somewhere.
I appreciate this attempted explanation, but it is completely inadequate. Still waiting for a good one.
-Archie
-- Archie L. Cobbs
On Thu, 26 Jan 2012 13:28:11 -0600, Archie Cobbs wrote:
On Thu, Jan 26, 2012 at 12:28 PM, Claudio Freire klaussfreire@gmail.com wrote:
To attempt a justification as to why older RHEL distros still exist, non-opensuse repos get added with less frequency. Otherwise, it wouldn't be possible to keep them all, just as it isn't possible with opensuse ones. You have to draw a line somewhere.
I appreciate this attempted explanation, but it is completely inadequate. Still waiting for a good one.
What exactly is inadequate about it?
1. You're using a free distribution 2. You're using services that are provided for free 3. Those services require disk storage, bandwidth, and other resources that aren't free. 4. Since those resources aren't free, it's not possible to keep everything for all versions going back forever. 5. That means that when resources are constrained, something gets clipped, and the logical starting place is to start with the oldest stuff.
If you want something that's got LTS, SUSE has some commercial options with the resources necessary paid for by licensing fees paid by customers so the support is retained for a longer period.
Free (as in beer) does have its limitations.
Jim
On Thu, Jan 26, 2012 at 7:41 PM, Jim Henderson hendersj@gmail.com wrote:
On Thu, 26 Jan 2012 13:28:11 -0600, Archie Cobbs wrote:
On Thu, Jan 26, 2012 at 12:28 PM, Claudio Freire klaussfreire@gmail.com wrote:
To attempt a justification as to why older RHEL distros still exist, non-opensuse repos get added with less frequency. Otherwise, it wouldn't be possible to keep them all, just as it isn't possible with opensuse ones. You have to draw a line somewhere.
I appreciate this attempted explanation, but it is completely inadequate. Still waiting for a good one.
What exactly is inadequate about it?
- You're using a free distribution
- You're using services that are provided for free
- Those services require disk storage, bandwidth, and other resources
that aren't free. 4. Since those resources aren't free, it's not possible to keep everything for all versions going back forever. 5. That means that when resources are constrained, something gets clipped, and the logical starting place is to start with the oldest stuff.
If you want something that's got LTS, SUSE has some commercial options with the resources necessary paid for by licensing fees paid by customers so the support is retained for a longer period.
Free (as in beer) does have its limitations.
Understood. I don't take anything for granted and understand that when it comes to service, you get what you pay for... and if you're paying nothing, you have a right to demand nothing. In addition I would even argue that OBS users have a moral responsibility to contribute back, in the form of patches, bug reports, builds of new software, etc. (and I try to do this).
I'm not demanding anything, just asking a fairly narrow question. I'm simply seeking to better understand, because my previous assumptions were obviously wrong.
Your #5 is:
"That means that when resources are constrained, something gets clipped, and the logical starting place is to start with the oldest stuff."
Sounds good to me! So let's look at the facts:
openSUSE 11.3: 1.5 years old, and is a SUSE distribution
RHEL 4: 7 years old, and is not a SUSE distribution
My simple question is: why openSUSE 11.3 before (for example) RHEL 4? What are the underlying priorities that resulted in that choice?
If the answer is "because 11.3 is EOL" well then I guess what I don't agree with is that equation. All openSUSE are (by definition) supported by their owners. These owners need the OBS repos in order to perform that support. If that support is unilaterally denied at the 18 month mark, then it dramatically reduces the usefulness of openSUSE for a large swath of possible use cases (basically, everything other than personal use).
OK, let's just admit the obvious: Novell is a business and it doesn't want to allow business' "mission critical" software to run on openSUSE because that represents lost revenue for SLES. Their enforcement mechanism is to limit openSUSE support to 18 months. While this is entirely in their right, this is a very blunt instrument. It is similar to the airlines charging you a higher price if you don't stay over a Saturday night: another blunt instrument targeted at business travelers.
However there is a difference between the airlines' business and the open source software business: the latter is a true ecosystem, where you depend on the contributions of your customers. Food for thought.
Thanks, -Archie
* Archie Cobbs archie.cobbs@gmail.com [01-27-12 10:15]:
If the answer is "because 11.3 is EOL" well then I guess what I don't agree with is that equation. All openSUSE are (by definition) supported by their owners. These owners need the OBS repos in order to perform that support. If that support is unilaterally denied at the 18 month mark, then it dramatically reduces the usefulness of openSUSE for a large swath of possible use cases (basically, everything other than personal use).
OK, let's just admit the obvious: Novell is a business and it doesn't want to allow business' "mission critical" software to run on openSUSE because that represents lost revenue for SLES. Their enforcement mechanism is to limit openSUSE support to 18 months. While this is entirely in their right, this is a very blunt instrument. It is similar to the airlines charging you a higher price if you don't stay over a Saturday night: another blunt instrument targeted at business travelers.
off-base Novell != openSUSE
While, as I read the conversations on the mail lists, consideration is given to Novell's business model but not *defining* the path of openSUSE. Novell has no "enforcement mechanism" in place. You are grasping straws and causing confusion, ie: spreading fud.
The lifetime of each issue of openSUSE is well documented.
On Fri, Jan 27, 2012 at 9:24 AM, Patrick Shanahan paka@opensuse.org wrote:
- Archie Cobbs archie.cobbs@gmail.com [01-27-12 10:15]:
If the answer is "because 11.3 is EOL" well then I guess what I don't agree with is that equation. All openSUSE are (by definition) supported by their owners. These owners need the OBS repos in order to perform that support. If that support is unilaterally denied at the 18 month mark, then it dramatically reduces the usefulness of openSUSE for a large swath of possible use cases (basically, everything other than personal use).
OK, let's just admit the obvious: Novell is a business and it doesn't want to allow business' "mission critical" software to run on openSUSE because that represents lost revenue for SLES. Their enforcement mechanism is to limit openSUSE support to 18 months. While this is entirely in their right, this is a very blunt instrument. It is similar to the airlines charging you a higher price if you don't stay over a Saturday night: another blunt instrument targeted at business travelers.
off-base Novell != openSUSE
While, as I read the conversations on the mail lists, consideration is given to Novell's business model but not *defining* the path of openSUSE. Novell has no "enforcement mechanism" in place. You are grasping straws and causing confusion, ie: spreading fud.
OK, if that's true then that makes things much simpler. If Novell is not influencing this process, then that means the community gets to fully decide.
In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.
I'm guessing there are many others out there who would like to "redefine" it.
-Archie
On Fri, Jan 27, 2012 at 12:35 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.
I'm guessing there are many others out there who would like to "redefine" it.
Why not bring evergreen into the equation?
Ie: synchronize EOL with incorporation into evergreen.
Right now the real problem is that 11.3 isn't in evergreen. If it was, all this would be moot.
Read this[0] thread. It requires quite a lot of manpower to be able to do so. Evergreen needs more people. So, gather volunteers. It's about backporting patches, IIRC, not major development.
[0] http://lists.rosenauer.org/pipermail/evergreen/2012-January/000560.html
On Fri, Jan 27, 2012 at 9:46 AM, Claudio Freire klaussfreire@gmail.com wrote:
On Fri, Jan 27, 2012 at 12:35 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.
I'm guessing there are many others out there who would like to "redefine" it.
Why not bring evergreen into the equation?
Ie: synchronize EOL with incorporation into evergreen.
Right now the real problem is that 11.3 isn't in evergreen. If it was, all this would be moot.
Read this[0] thread. It requires quite a lot of manpower to be able to do so. Evergreen needs more people. So, gather volunteers. It's about backporting patches, IIRC, not major development.
[0] http://lists.rosenauer.org/pipermail/evergreen/2012-January/000560.html
Evergreen is a noble idea, with a good number of people interested (see thread above), yet it has stalled and there seem to be no plans by the OBS team to accommodate the idea.
Really, the fact that Evergreen even exists is ridiculous.
There are a bunch of people who need basic openSUSE repo availability to last more than 1.5 years, but their needs are not being addressed.
And it seems like such a simple thing! But I don't know enough about the operation of OBS to advise intelligently.
Do we need to start fundraising for more disk drives?? I'm curious to hear more informed opinions.
-Archie
On Fri, Jan 27, 2012 at 10:47:57AM -0600, Archie Cobbs wrote:
On Fri, Jan 27, 2012 at 9:46 AM, Claudio Freire klaussfreire@gmail.com wrote:
On Fri, Jan 27, 2012 at 12:35 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.
I'm guessing there are many others out there who would like to "redefine" it.
Why not bring evergreen into the equation?
Ie: synchronize EOL with incorporation into evergreen.
Right now the real problem is that 11.3 isn't in evergreen. If it was, all this would be moot.
Read this[0] thread. It requires quite a lot of manpower to be able to do so. Evergreen needs more people. So, gather volunteers. It's about backporting patches, IIRC, not major development.
[0] http://lists.rosenauer.org/pipermail/evergreen/2012-January/000560.html
Evergreen is a noble idea, with a good number of people interested (see thread above), yet it has stalled and there seem to be no plans by the OBS team to accommodate the idea.
Really, the fact that Evergreen even exists is ridiculous.
There are a bunch of people who need basic openSUSE repo availability to last more than 1.5 years, but their needs are not being addressed.
And it seems like such a simple thing! But I don't know enough about the operation of OBS to advise intelligently.
Do we need to start fundraising for more disk drives?? I'm curious to hear more informed opinions.
Real disk storage and compute power.
The 18 months are however mostly a manpower issue. Maintenance and security is still being coordinated 100% by SUSE employees. With 12.1 we are currently switching to a model where commnunity members can be integrated in the full process.
So if community members do maintenance of openSUSE x.y, it basically never needs to end. Just SUSE mandates only 18 months currently.
Ciao, Marcus
On 1/27/2012 11:47 AM, Archie Cobbs wrote:
On Fri, Jan 27, 2012 at 9:46 AM, Claudio Freireklaussfreire@gmail.com wrote:
On Fri, Jan 27, 2012 at 12:35 PM, Archie Cobbsarchie.cobbs@gmail.com wrote:
In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.
I'm guessing there are many others out there who would like to "redefine" it.
Why not bring evergreen into the equation?
Ie: synchronize EOL with incorporation into evergreen.
Right now the real problem is that 11.3 isn't in evergreen. If it was, all this would be moot.
Read this[0] thread. It requires quite a lot of manpower to be able to do so. Evergreen needs more people. So, gather volunteers. It's about backporting patches, IIRC, not major development.
[0] http://lists.rosenauer.org/pipermail/evergreen/2012-January/000560.html
Evergreen is a noble idea, with a good number of people interested (see thread above), yet it has stalled and there seem to be no plans by the OBS team to accommodate the idea.
Really, the fact that Evergreen even exists is ridiculous.
There are a bunch of people who need basic openSUSE repo availability to last more than 1.5 years, but their needs are not being addressed.
And it seems like such a simple thing! But I don't know enough about the operation of OBS to advise intelligently.
Do we need to start fundraising for more disk drives?? I'm curious to hear more informed opinions.
-Archie
I would definitely chip in for more opensuse repo lifetime, and for more manpower to uphold a higher standard in the opensuse product wrt stability of interface , predictability, backward compatibility, general polish "if there's a button, it works".
The usual response is "you want SLE". No, I do not want a cul-de-sac proprietary product environment that is somewhat like opensuse but different enough that packages and documentation and procedures etc for opensuse do not always apply to sle NOR vice versa.
If I spend time working on a package, or documenting a procedure, and I'm giving my time away, then I want the result to be applicable to everyone else for free as I intended instead of some subset of people that pay Novell being the only ones that benefit. If I wanted that, I'd have done the work for pay and just my own customers would benefit.
And when I look for help or clues from others experiences, I want to have a large pool of data to work from, not just the people who for some reason pay for SLE.
"It's a free thing, you have no right to expectations" is a crap argument. Why bother working on a thing at all if you and the other people working on it do not mostly want it to be excellent?
"X is willing to do the work so X gets to say how it goes." is also a crap argument. I'm "willing to do the work" to fix the text mode server model so that it has no branding or graphics anywhere in it, no splashy or gfxboot, unhacked upstream versions of grub & syslinux, no kdm, etc, but it ain't happening. And anybody can be willing to do the work for all manner of horrible ideas (systemd), but that shouldn't be enough of a reason to allow it to happen.
There are just a lot of problems with the reponses to various complaints that I and others have raised in general. It's just starting to feel like the main opensuse contributors are no longer interested in making a system that's actually useful for others, instead mostly interested in amusing themselves.
I haven't tracked other distros development closely so I don't know, it may be the same everywhere and maybe opensuse is no worse than any other in this respect. It may just be a generational thing.
But back on topic, I'd pay for more repo lifetime.
Also svn/git-like revision histories of spec files. Like what the wiki does. So you don't have to lose the various optimal points that are reached and then lost along the way right now, where a newer package might be possible to build on some older target, and it existed for a while, but now the knowledge of that is lost because the current version of that package isn't buildable on that old target, and the spec and src.rpm from that time no longer exist, maybe the whole repo no longer exists ala kotd, server:monitoring, etc, only the current ones and the much older ones that shipped with that older target and nothing in between.
On Sat, 28 Jan 2012 06:40:15 -0500 "Brian K. White" brian@aljex.com wrote:
But back on topic, I'd pay for more repo lifetime.
Hi You can always create you own OBS (as in the obs server) environment and keep things going locally?
How much would you pay per annum?
I'm only a home user, but use SLED as well (with the SDK I get most of the other stuff found in SLE, on OBS and build myself), the last three year subscription to updates was US$35 per year.
On 1/28/2012 1:35 PM, Malcolm wrote:
On Sat, 28 Jan 2012 06:40:15 -0500 "Brian K. White"brian@aljex.com wrote:
But back on topic, I'd pay for more repo lifetime.
Hi You can always create you own OBS (as in the obs server) environment and keep things going locally?
I do exactly that already. But it's incomplete. I only mirror my own little home repo and the main oss, non-oss, & updates repos for for i386 and x86_64, no src, no ppc, no other of the zillion home and devel repos, and no roll-back-able history for the spec files.
But at least I have a few packages building current or at least a lot more-current for targets back to 10.0, and I have my own mirrors of oss, non-oss, and updates repos for 10.0 and up. So when I need to install something new on 10.0 I still can.
How much would you pay per annum?
I'm only a home user, but use SLED as well (with the SDK I get most of the other stuff found in SLE, on OBS and build myself), the last three year subscription to updates was US$35 per year.
Less than $100 per machine per year, but that's already thousands even for a modest operation. But I won't invest in a closed product or a unless I have no other choice. So I won't invest in SLE* when it has any source or binaries or repos that aren't equally freely available for all. Maybe I'd pay more if asked politely and I thought it was going where I wanted it to go and convinced it wasn't a wasted gesture like if too few others were doing likewise. But I won't have even $10 extracted by coercion. I don't need to get any personal service for that price either.
It's not about not paying for value. It's about paying for uncountably wide spread and long term value instead of short term dead-end value.
You have to help create the world you want to live in. I happen to hate the traditional software world of bombs hooked to treadmills. So you have to start living without whatever people are selling the old way no matter how nice it may look, and start paying the people who are giving their stuff away free. At least for software, art, and other information, which has only a high creation and development cost and not a high dissemination cost.
On Saturday, January 28, 2012 06:40:15 Brian K. White wrote:
On 1/27/2012 11:47 AM, Archie Cobbs wrote:
On Fri, Jan 27, 2012 at 9:46 AM, Claudio Freireklaussfreire@gmail.com
wrote:
On Fri, Jan 27, 2012 at 12:35 PM, Archie Cobbsarchie.cobbs@gmail.com
wrote:
In which case, I think we should survey our community and see how many people are happy with the rapid deathcycle of openSUSE releases.
I'm guessing there are many others out there who would like to "redefine" it.>>
Why not bring evergreen into the equation?
Ie: synchronize EOL with incorporation into evergreen.
Right now the real problem is that 11.3 isn't in evergreen. If it was, all this would be moot.
Read this[0] thread. It requires quite a lot of manpower to be able to do so. Evergreen needs more people. So, gather volunteers. It's about backporting patches, IIRC, not major development.
[0] http://lists.rosenauer.org/pipermail/evergreen/2012-January/000560.ht ml>
Evergreen is a noble idea, with a good number of people interested (see thread above), yet it has stalled and there seem to be no plans by the OBS team to accommodate the idea.
Really, the fact that Evergreen even exists is ridiculous.
There are a bunch of people who need basic openSUSE repo availability to last more than 1.5 years, but their needs are not being addressed.
And it seems like such a simple thing! But I don't know enough about the operation of OBS to advise intelligently.
Do we need to start fundraising for more disk drives?? I'm curious to hear more informed opinions.
-Archie
I would definitely chip in for more opensuse repo lifetime, and for more manpower to uphold a higher standard in the opensuse product wrt stability of interface , predictability, backward compatibility, general polish "if there's a button, it works".
The usual response is "you want SLE". No, I do not want a cul-de-sac proprietary product environment that is somewhat like opensuse but different enough that packages and documentation and procedures etc for opensuse do not always apply to sle NOR vice versa.
If I spend time working on a package, or documenting a procedure, and I'm giving my time away, then I want the result to be applicable to everyone else for free as I intended instead of some subset of people that pay Novell being the only ones that benefit. If I wanted that, I'd have done the work for pay and just my own customers would benefit.
And when I look for help or clues from others experiences, I want to have a large pool of data to work from, not just the people who for some reason pay for SLE.
"It's a free thing, you have no right to expectations" is a crap argument. Why bother working on a thing at all if you and the other people working on it do not mostly want it to be excellent?
"X is willing to do the work so X gets to say how it goes." is also a crap argument. I'm "willing to do the work" to fix the text mode server model so that it has no branding or graphics anywhere in it, no splashy or gfxboot, unhacked upstream versions of grub & syslinux, no kdm, etc, but it ain't happening. And anybody can be willing to do the work for all manner of horrible ideas (systemd), but that shouldn't be enough of a reason to allow it to happen.
There are just a lot of problems with the reponses to various complaints that I and others have raised in general. It's just starting to feel like the main opensuse contributors are no longer interested in making a system that's actually useful for others, instead mostly interested in amusing themselves.
I haven't tracked other distros development closely so I don't know, it may be the same everywhere and maybe opensuse is no worse than any other in this respect. It may just be a generational thing.
But back on topic, I'd pay for more repo lifetime.
Also svn/git-like revision histories of spec files. Like what the wiki does. So you don't have to lose the various optimal points that are reached and then lost along the way right now, where a newer package might be possible to build on some older target, and it existed for a while, but now the knowledge of that is lost because the current version of that package isn't buildable on that old target, and the spec and src.rpm from that time no longer exist, maybe the whole repo no longer exists ala kotd, server:monitoring, etc, only the current ones and the much older ones that shipped with that older target and nothing in between.
The point is this: SUSE is the one who pays for openSUSE's lifetime. As in, SUSE pays the people working on security updates and fixes. SUSE pays the server space and processing power. We are committed to pay for keeping 2 openSUSE versions maintained and alive with a few months bonus. We're not going to pay for more as it is expensive and doing so would cut in our income - we're not exactly trying to kill our own company and land all our engineers on the street.
All that seems to me to be very much a community thing: a community member (SUSE) does work. When SUSE stops doing that work and nobody takes over, well, it stops. If someone wants to take over (like Wolfgang did) or pay to keep it alive: awesome. If you are willing to pay to keep openSUSE 11.3 alive for say 2 more years I'd be happy to try and get you a quote for support. If you think it's stupid to pay for such a service and you don't want to do the work, well, what do you expect?
SUSE employees need to eat and donations won't pay for that. Heck, selling the openSUSE Box makes so little money we don't even bother anymore...
I see nothing that warrants the anger you and Archie are displaying, sorry.
About the "but why RHEL and not openSUSE 11.3" - simple, we keep versions which are actively maintained. RHEL is, openSUSE 11.3 is not.
On Tue, Jan 31, 2012 at 6:22 AM, Jos Poortvliet jos@opensuse.org wrote:
The point is this: SUSE is the one who pays for openSUSE's lifetime. As in, SUSE pays the people working on security updates and fixes. SUSE pays the server space and processing power. We are committed to pay for keeping 2 openSUSE versions maintained and alive with a few months bonus. We're not going to pay for more as it is expensive and doing so would cut in our income
- we're not exactly trying to kill our own company and land all our engineers
on the street.
Hmm... I think there is a subtlety here that is worth mentioning...
I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories.
In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself.
What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines.
So here's my question: why not let 11.3 just "live on", without any official maintenance?
Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them.
It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done.
This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/
This seems like a simple compromise that would address most of what both sides of this discussion want.
What do you think?
-Archie
On 1/31/2012 12:24 PM, Archie Cobbs wrote:
On Tue, Jan 31, 2012 at 6:22 AM, Jos Poortvlietjos@opensuse.org wrote:
The point is this: SUSE is the one who pays for openSUSE's lifetime. As in, SUSE pays the people working on security updates and fixes. SUSE pays the server space and processing power. We are committed to pay for keeping 2 openSUSE versions maintained and alive with a few months bonus. We're not going to pay for more as it is expensive and doing so would cut in our income
- we're not exactly trying to kill our own company and land all our engineers
on the street.
Hmm... I think there is a subtlety here that is worth mentioning...
I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories.
In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself.
What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines.
So here's my question: why not let 11.3 just "live on", without any official maintenance?
Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them.
It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done.
This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/
This seems like a simple compromise that would address most of what both sides of this discussion want.
What do you think?
-Archie
It would pretty quickly begin to take up a LOT more storage space. It's not nearly a free proposition.
But like I said, and like he ignored, I'd be willing to pay for MY SHARE of more storage and lifetime. Of course I can't do it all myself. Yet another stupid response designed to end the discussion without actually reflecting on the fact that there is a problem and it is addressable.
I never heard any response from the question below from the openSUSE folks.
Is this idea feasible?
Thanks, -Archie
On Tue, Jan 31, 2012 at 11:24 AM, Archie Cobbs archie.cobbs@gmail.com wrote:
I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories.
In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself.
What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines.
So here's my question: why not let 11.3 just "live on", without any official maintenance?
Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them.
It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done.
This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/
This seems like a simple compromise that would address most of what both sides of this discussion want.
What do you think?
-- Archie L. Cobbs
* Archie Cobbs archie.cobbs@gmail.com [02-12-12 18:04]:
I never heard any response from the question below from the openSUSE folks.
Is this idea feasible?
Thanks, -Archie
On Tue, Jan 31, 2012 at 11:24 AM, Archie Cobbs archie.cobbs@gmail.com wrote:
I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories.
In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself.
What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines.
So here's my question: why not let 11.3 just "live on", without any official maintenance?
Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them.
It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done.
This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/
This seems like a simple compromise that would address most of what both sides of this discussion want.
What do you think?
I would guess that you do not read this forum from your question. 11.3 and other do _live_ on w/o maintenance, see: http://download.opensuse.org/repositories/DISCONTINUED:/openSUSE:/
Am Sonntag, 12. Februar 2012, 17:03:24 schrieb Archie Cobbs:
I never heard any response from the question below from the openSUSE folks.
Is this idea feasible?
As written quite some times ago, because it harms our mirrors and our build power. And we have way too many people not caring about to remove repos when it does not work properly anymore. So instead of opt-out, we have opt-in by using the DISCONTINUED:* project repositories.
bye adrian
Thanks, -Archie
On Tue, Jan 31, 2012 at 11:24 AM, Archie Cobbs archie.cobbs@gmail.com
wrote:
I realize security updates and fixes are costly, but for me that's actually not as important as simply having basic access to the repositories.
In other words, I don't have a problem with SUSE not actively supporting 11.3 with updates and security fixes. For example, I have one 11.3 system which is working fine and only accessible from the outside world via SSH. So the only security issues I need to worry about are SSH bugs, and fortunately those are few and far enough between that I can manage them myself.
What really hurts though is that the existing 11.3 repos of every OBS project were unilaterally deleted, which means now I can no longer even build 11.3 machines.
So here's my question: why not let 11.3 just "live on", without any official maintenance?
Let the laggards like me who continue to use it worry about security fixes and updates. And let each OBS project decide when supporting 11.3 builds is too much of a pain, instead of deciding for them.
It seems that doing this this would only require a little more disk space and CPU power. It would allow lots of people who rely on stable systems to continue to be able to build and maintain those systems. As you pointed out, disk and CPU are not primary drivers of what gets kept, "actively maintained" is. So declare 11.3 "actively maintained but without updates or security fixes" and we're done.
This would be analogous to RedHat's "Extended Life Phase" (which RHEL 4 will enter in February): see https://access.redhat.com/support/policy/updates/errata/
This seems like a simple compromise that would address most of what both sides of this discussion want.
What do you think?
-- Archie L. Cobbs
On Mon, Feb 13, 2012 at 3:00 AM, Adrian Schröter adrian@suse.de wrote:
Am Sonntag, 12. Februar 2012, 17:03:24 schrieb Archie Cobbs:
I never heard any response from the question below from the openSUSE folks.
Is this idea feasible?
As written quite some times ago, because it harms our mirrors and our build power. And we have way too many people not caring about to remove repos when it does not work properly anymore. So instead of opt-out, we have opt-in by using the DISCONTINUED:* project repositories.
I don't think that is the same thing as what I'm suggesting, and practically speaking, it's not a workable solution.
Here's the difference: today, if I want to (re)build a 11.3 server, I have to go find the maintainers of 15 different OBS projects and annoy them by asking them to add DISCONTINUED:11.3. Then of course every six months I have to do the same thing all over again.
And of course, only if I'm lucky enough to get 100% positive response can I build my 11.3 server. If the maintainer of, say, server:monitoring is just too busy or doesn't care about 11.3, we're out of luck forever.
In other words, the fact that you are unilaterally deleting repos after 18 months means - practically speaking - there's no way to get them back.
OK, let's try an even weaker proposal: declare that the last openSUSE version in each series (e.g., 11.4 for the 11.X series) is allowed to live a lot longer than 18 months, though not "officially supported". When it's 18 months are up, don't delete it, just leave it alone, so people can still use it. If some project doesn't want to keep it around they can choose to delete it themselves, but don't force it on them.
-Archie
On Mon, Feb 13, 2012 at 10:02 AM, Archie Cobbs archie.cobbs@gmail.com wrote:
On Mon, Feb 13, 2012 at 3:00 AM, Adrian Schröter adrian@suse.de wrote:
Am Sonntag, 12. Februar 2012, 17:03:24 schrieb Archie Cobbs:
I never heard any response from the question below from the openSUSE folks.
Is this idea feasible?
As written quite some times ago, because it harms our mirrors and our build power. And we have way too many people not caring about to remove repos when it does not work properly anymore. So instead of opt-out, we have opt-in by using the DISCONTINUED:* project repositories.
I don't think that is the same thing as what I'm suggesting, and practically speaking, it's not a workable solution.
Here's the difference: today, if I want to (re)build a 11.3 server, I have to go find the maintainers of 15 different OBS projects and annoy them by asking them to add DISCONTINUED:11.3. Then of course every six months I have to do the same thing all over again.
And of course, only if I'm lucky enough to get 100% positive response can I build my 11.3 server. If the maintainer of, say, server:monitoring is just too busy or doesn't care about 11.3, we're out of luck forever.
In other words, the fact that you are unilaterally deleting repos after 18 months means - practically speaking - there's no way to get them back.
OK, let's try an even weaker proposal: declare that the last openSUSE version in each series (e.g., 11.4 for the 11.X series) is allowed to live a lot longer than 18 months, though not "officially supported". When it's 18 months are up, don't delete it, just leave it alone, so people can still use it. If some project doesn't want to keep it around they can choose to delete it themselves, but don't force it on them.
-Archie
Archie,
I assume you know about the Evergreen project.
http://en.opensuse.org/Evergreen
A better proposal than yours in my mind would be for Evergreen supported openSUSE releases not have their sources in OBS renamed to discontinued until evergreen support drops.
There is a current discussion thread on opensuse-project where it looks like 11.4 is likely to be designated the next evergreen release.
If that works for you, I suggest you speak up in that thread.
Greg
On Mon, Feb 13, 2012 at 9:17 AM, Greg Freemyer greg.freemyer@gmail.com wrote:
A better proposal than yours in my mind would be for Evergreen supported openSUSE releases not have their sources in OBS renamed to discontinued until evergreen support drops.
Yes. This is simply the union of what we both want :)
There is a current discussion thread on opensuse-project where it looks like 11.4 is likely to be designated the next evergreen release.
Evergreen is a great idea and I like it. My only problem is that it shouldn't have to exist.
Let me try to be a little bit philosophical...
I think this quote from Carlos (on opensuse-project) hints at the root cause of all the trouble:
"Carlos E. R." <> wrote:
No, the team doing the dev and packaging have different goals than a long time support.
According to this statement, package maintainers are not interested in working towards the goal of stable versions of packages running on stable long term versions of openSUSE.
However, I'm not sure that's actually true.
Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.
In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.
So what happens? They either try to shoehorn foobar-2.1 onto 11.3, with lots of resulting build issues, or if that becomes too hard they just drop support for 11.3 or leave the build broken.
Some brave projects are willing to spawn sub-projects for each openSUSE version, e.g. Virtualization:openSUSE11.3. But this is unwieldy and hard to manage, and as a result most projects don't bother to do this.
(dreaming) Why not let each project be a simple git repo, with a branch for each repository, defaulting to 'master' if no such branch were defined?
(back to reality) In other words, I'm suggesting we think about how improving the structure of OBS might make it easier to please everyone, instead of forcing a bias against long term support.
-Archie
Archie Cobbs (archie.cobbs@gmail.com) wrote:
Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.
In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.
So what happens? They either try to shoehorn foobar-2.1 onto 11.3, with lots of resulting build issues, or if that becomes too hard they just drop support for 11.3 or leave the build broken.
Some brave projects are willing to spawn sub-projects for each openSUSE version, e.g. Virtualization:openSUSE11.3. But this is unwieldy and hard to manage, and as a result most projects don't bother to do this.
I'm very new to the OBS, but I agree - to my inexperienced eyes, it does seem like there could be a more elegant solution.
(dreaming) Why not let each project be a simple git repo, with a branch for each repository, defaulting to 'master' if no such branch were defined?
Right, that was also my first reaction too the first time I found myself in a twisty maze of OBS repositories, all alike. Could it make sense to switch the OBS backend to git? Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge?
Adam Spiers (aspiers@suse.com) wrote:
Archie Cobbs (archie.cobbs@gmail.com) wrote:
(dreaming) Why not let each project be a simple git repo, with a branch for each repository, defaulting to 'master' if no such branch were defined?
Right, that was also my first reaction too the first time I found myself in a twisty maze of OBS repositories, all alike.
Speaking of twisty mazes, here's a scenario I just found myself :-(
I'm working on improving some of the OBS source services, during which I noticed that 'obsrun' is a standard user/group used by the OBS backend. However, when building from .spec files which reference this in the %files section, rpmlint complains:
obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.
So, wanting to be a good citizen, I branched and made the change. Before sending the submitrequest, I wanted to test it, so I did an 'osc build' locally, installed the resulting rpm, and then rebuilt obs-service-tar_scm, hoping to see the warning disappear. Unfortunately it was a lot harder than that!
TL;DR summary -------------
- rpmlint-mini.spec pulls in files from /usr on the build host; isn't that evil and wrong? - Why does rpmlint-mini include its own Python? - Why does rpmlint-mini even exist - isn't rpmlint good enough? - If submitrequests for rpmlint are to be encouraged, IMHO this all needs to be made a lot more obvious.
The full saga -------------
I'm not entirely sure what the moral of this story is, but I'm including it here in case it's of use to anyone in the future ...
First I found out that osc build doesn't use the rpmlint rpm at build-time; it uses rpmlint-mini, and rpmlint-Factory (even if not building for Factory, I think). The latter seems to be just a small layer of additional rpmlint configuration though.
OK, so I needed to get my change into rpmlint-mini somehow. Looking in its .spec file, I saw the %install section has some very strange lines - in particular:
install -m 644 -D /usr/share/rpmlint/config $RPM_BUILD_ROOT/opt/testing/share/rpmlint/config
So the contents of the rpmlint-mini rpm you are building will depend directly on whichever rpmlint config you happened to have installed on the build machine at build-time! I thought that there was a golden rule about .spec files only referring to sources in the SOURCES/ directory, otherwise the generated .src.rpm will not contain all the sources required to be able to consistently reproduce the same binary .rpm. Did I get that wrong, or is there a good reason why rpmlint-mini should be an exception to this rule?
Anyway, I figured that if I rebuilt rpmlint-mini on the same machine which had my patched rpmlint installed, it would inherit the same patched config via the install line above. However, rpmlint-mini also contains:
%define _use_internal_dependency_generator 0 %define __find_requires %my_requires
The point of this seems to be to ensure that all packages found by the built-in %{__find_provides} are filtered out of the resulting 'requires' list. I'm guessing that this is something to do with the way that rpmlint-mini contains its own copy of Python (why?!), but the end result is that my freshly built rpmlint-mini includes the following dependencies:
... auto: libc.so.6()(64bit) auto: libc.so.6(GLIBC_2.11)(64bit) auto: libc.so.6(GLIBC_2.14)(64bit) auto: libc.so.6(GLIBC_2.15)(64bit) ...
In particular, the dependency on glibc 2.15 presumably comes from the rpm being built inside an openSUSE Factory buildroot. So that means I can only install it inside the buildroot, not on the 12.1 host:
sudo rpm -Uhv /var/tmp/build-root/openSUSE_Factory/x86_64/home/abuild/rpmbuild/RPMS/x86_64/rpmlint-mini-1.3-0.x86_64.rpm error: Failed dependencies: libc.so.6(GLIBC_2.15)(64bit) is needed by rpmlint-mini-1.3-0.x86_64
But that's OK, because it's the buildroot which needs it anyway. Unfortunately installing it in the buildroot doesn't work either, because /usr/lib/build/init_buildsystem happily replaces it with the unpatched version every time:
processing specfile /home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec ... running changelog2spec --target rpm --file /home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec init_buildsystem --cachedir /var/cache/build --rpmlist /tmp/rpmlist.Zl1T5W /home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec ... reordering...cycle: gio-branding-upstream -> libgio-2_0-0 breaking dependency libgio-2_0-0 -> gio-branding-upstream cycle: libcrack2 -> cracklib breaking dependency libcrack2 -> cracklib done deleting unwanted rpmlint-1.3-0 installing rpmlint-1.3-109.1
Next I tried injecting the patched rpmlint rpm into /var/tmp/osbuild-packagecache, but that didn't work either. After wading through /usr/lib/build/{build,init_buildsystem}, I finally found that the list of rpms to install in the buildroot is actually generated and passed into build by osc, and there's a nice --prefer-pkgs=DIR option to osc build which enabled me to ensure that my patched rpmlint was installed in the buildroot whilst rpmlint-mini was built. Then I could finally copy the patched rpmlint-mini back to the preferred package directory and rebuild my source service to ensure that the non-standard-[ug]id warnings no longer appeared. They didn't - hooray! So here's the request:
https://build.opensuse.org/request/show/104823
Adam Spiers wrote:
- rpmlint-mini.spec pulls in files from /usr on the build host; isn't that evil and wrong?
- Why does rpmlint-mini include its own Python?
- Why does rpmlint-mini even exist - isn't rpmlint good enough?
Plain rpmlint cannot be used in the build root as it would introduce python in each every build root. Therefore rpmlint-mini collects all necessary files from python and rpmlint and pre-compiles them to create a stand-alone package. The rpmlint-mini package is not meant to be used on real sytems, it's just a special hack for the build root.
First I found out that osc build doesn't use the rpmlint rpm at build-time; it uses rpmlint-mini, and rpmlint-Factory (even if not building for Factory, I think). The latter seems to be just a small layer of additional rpmlint configuration though.
Yes, rpmlint-Factory is a bit of a misnomer, rpmlint-policy-openSUSE or something like that would be better suited. It only contains badness settings.
https://build.opensuse.org/request/show/104823
Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.
cu Ludwig
Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:
Adam Spiers wrote:
...
https://build.opensuse.org/request/show/104823Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.
Please buildrequire obs-server in such situations, it does this.
bye adrian
Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:
Adam Spiers wrote:
...
https://build.opensuse.org/request/show/104823Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.
Please buildrequire obs-server in such situations, it does this.
Well, please submit to Factory then.
cu Ludwig
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:
Adam Spiers wrote:
...
https://build.opensuse.org/request/show/104823Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.
Please buildrequire obs-server in such situations, it does this.
Well, please submit to Factory then.
I added obs-server to BuildRequires but I still get non-standard-[ug]id warnings.
Am Dienstag, 14. Februar 2012, 10:01:28 schrieb Adam Spiers:
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:
Adam Spiers wrote:
...
https://build.opensuse.org/request/show/104823Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.
Please buildrequire obs-server in such situations, it does this.
Well, please submit to Factory then.
I added obs-server to BuildRequires but I still get non-standard-[ug]id warnings.
Seems to be a generic problem ... It seems to be impossible to use OBS with default configs to build addon packages which are not supposed to be submitted to factory (like obs-server and therefore no obsrun user will be defined in Factory)...
Dunno how rpmlint is supposed to detect official factory packages and pure addons ...
Am 14.02.2012 09:42, schrieb Adrian Schröter:
Am Dienstag, 14. Februar 2012, 09:31:50 schrieb Ludwig Nussel:
Adam Spiers wrote:
...
https://build.opensuse.org/request/show/104823Hmm. So the package obs-service-download_files creates a user it actually doesn't have anything to do with!? I guess there should be e.g. a obs-filesystem package that creates the user and owns some basic directories.
Please buildrequire obs-server in such situations, it does this.
Factory packages can't require packages not in factory, so obs-filesystem sounds like a good compromise if you don't want or can't maintain obs in factory (with its long development cycle it shold be fine though *huest*).
Greetings, Stephan
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adam Spiers wrote:
- rpmlint-mini.spec pulls in files from /usr on the build host; isn't that evil and wrong?
- Why does rpmlint-mini include its own Python?
- Why does rpmlint-mini even exist - isn't rpmlint good enough?
Plain rpmlint cannot be used in the build root as it would introduce python in each every build root.
Sure - my question was really "why can't we have Python in every build root?"
Adam Spiers wrote:
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adam Spiers wrote:
- rpmlint-mini.spec pulls in files from /usr on the build host; isn't that evil and wrong?
- Why does rpmlint-mini include its own Python?
- Why does rpmlint-mini even exist - isn't rpmlint good enough?
Plain rpmlint cannot be used in the build root as it would introduce python in each every build root.
Sure - my question was really "why can't we have Python in every build root?"
That would make every single package implicitly build depend on python. The amount of default installed packages needs to be reduced rather than adding even more. See efforts to remove automake etc from the default set.
cu Ludwig
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adam Spiers wrote:
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adam Spiers wrote:
- rpmlint-mini.spec pulls in files from /usr on the build host; isn't that evil and wrong?
- Why does rpmlint-mini include its own Python?
- Why does rpmlint-mini even exist - isn't rpmlint good enough?
Plain rpmlint cannot be used in the build root as it would introduce python in each every build root.
Sure - my question was really "why can't we have Python in every build root?"
That would make every single package implicitly build depend on python.
But every single package does already, it's just hidden inside rpmlint-mini. What's the advantage of doing that?
The amount of default installed packages needs to be reduced rather than adding even more.
For speeding up builds, or other reasons?
Am Dienstag, 14. Februar 2012, 15:37:11 schrieb Adam Spiers:
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adam Spiers wrote:
Ludwig Nussel (ludwig.nussel@suse.de) wrote:
Adam Spiers wrote:
rpmlint-mini.spec pulls in files from /usr on the build host;
isn't that evil and wrong?
Why does rpmlint-mini include its own Python?
Why does rpmlint-mini even exist - isn't rpmlint good enough?
Plain rpmlint cannot be used in the build root as it would introduce python in each every build root.
Sure - my question was really "why can't we have Python in every build root?"
That would make every single package implicitly build depend on python.
But every single package does already, it's just hidden inside rpmlint-mini. What's the advantage of doing that?
The amount of default installed packages needs to be reduced rather than adding even more.
For speeding up builds, or other reasons?
for that and to avoiding cycles which makes it hard to bootstrap a system.
Am 14.02.2012 01:09, schrieb Adam Spiers:
obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.
This is a bug in the package if you ask me. the service package can be installed on every developer's machine and packaging it in a way that it only works on OBS server instances is *wrong*.
Gretings, Stephan
Am Dienstag, 14. Februar 2012, 10:22:22 schrieb Stephan Kulow:
Am 14.02.2012 01:09, schrieb Adam Spiers:
obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun> A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.This is a bug in the package if you ask me. the service package can be installed on every developer's machine and packaging it in a way that it only works on OBS server instances is *wrong*.
True, a reason to add obsrun user in this package to avoid to require obs- server.
However, obs-server is never supposed to be to go into factory.
So a simple obs-filesystem package may be needed indeed :/
Gretings, Stephan
Adrian Schröter wrote:
However, obs-server is never supposed to be to go into factory.
Why?
cu Ludwig
Am Dienstag, 14. Februar 2012, 11:11:50 schrieb Ludwig Nussel:
Adrian Schröter wrote:
However, obs-server is never supposed to be to go into factory.
Why?
Because we don't maintain it in the same time time frames as openSUSE distros.
And given to the experiences of total destroyed user data with 12.1 changes I am really frightend to run an OBS on a moving target.
cu Ludwig
Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 11:11:50 schrieb Ludwig Nussel:
Adrian Schröter wrote:
However, obs-server is never supposed to be to go into factory.
Why?
Because we don't maintain it in the same time time frames as openSUSE distros.
So? You have to deal with that in openSUSE:Tools just as well, right?
And given to the experiences of total destroyed user data with 12.1 changes I am really frightend to run an OBS on a moving target.
In which way are the 217 packages in openSUSE:Tools less of a moving target? That's more frightening to me at least.
cu Ludwig
Adrian Schröter (adrian@suse.de) wrote:
Am Dienstag, 14. Februar 2012, 11:11:50 schrieb Ludwig Nussel:
Adrian Schröter wrote:
However, obs-server is never supposed to be to go into factory.
Why?
Because we don't maintain it in the same time time frames as openSUSE distros.
And given to the experiences of total destroyed user data with 12.1 changes I am really frightend to run an OBS on a moving target.
I think that might be a lot less frightening if we had full test coverage. I know that is probably a huge amount of work and not going to happen overnight, but I am planning a submitrequest today which will be a tiny step in that direction :)
Am 14.02.2012 11:08, schrieb Adrian Schröter:
Am Dienstag, 14. Februar 2012, 10:22:22 schrieb Stephan Kulow:
Am 14.02.2012 01:09, schrieb Adam Spiers:
obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun> A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.This is a bug in the package if you ask me. the service package can be installed on every developer's machine and packaging it in a way that it only works on OBS server instances is *wrong*.
True, a reason to add obsrun user in this package to avoid to require obs- server.
No, it's not. Having the cache owned by obsrun won't fix anything as long as there is nothing running under this user. It's just a package that you install and it then spits in your face saying "sorry, for caching you need to fix me". So if it needs fixing anyway, then the obs boot scripts can just as well chown the directory to the user, OBS runs under.
Greetings, Stephan
Am Dienstag, 14. Februar 2012, 11:15:02 schrieb Stephan Kulow:
Am 14.02.2012 11:08, schrieb Adrian Schröter:
Am Dienstag, 14. Februar 2012, 10:22:22 schrieb Stephan Kulow:
Am 14.02.2012 01:09, schrieb Adam Spiers:
obs-service-tar_scm.noarch: W: non-standard-uid /var/cache/obs/tar_scm/repourl obsrun> A file in this package is owned by an unregistered user id. To register the user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add the user to the "config" file and send a submitrequest.This is a bug in the package if you ask me. the service package can be installed on every developer's machine and packaging it in a way that it only works on OBS server instances is *wrong*.
True, a reason to add obsrun user in this package to avoid to require obs- server.
No, it's not. Having the cache owned by obsrun won't fix anything as long as there is nothing running under this user. It's just a package that you install and it then spits in your face saying "sorry, for caching you need to fix me". So if it needs fixing anyway, then the obs boot scripts can just as well chown the directory to the user, OBS runs under.
There are no obs boot scripts running on developer workstations who use this just via osc.
Greetings, Stephan
Am 14.02.2012 11:17, schrieb Adrian Schröter:
There are no obs boot scripts running on developer workstations who use this just via osc.
Right! And so it's pointless to have it owned by obsrun if no obs runs. "nobody" will do.
Greetings, Stephan
Stephan Kulow (coolo@suse.de) wrote:
Am 14.02.2012 11:17, schrieb Adrian Schröter:
There are no obs boot scripts running on developer workstations who use this just via osc.
Right! And so it's pointless to have it owned by obsrun if no obs runs. "nobody" will do.
Well, this raises the question of security. Something called /var/cache/obs is clearly system-wide, but we don't want to allow multiple users on a non-OBS-server share the same cache (01777 permissions), because one user could poison the cache and cause another user to build trojaned packages. 01755 would work for the download_files service, but not for tar_scm where any user needs to be able to trigger an update of an existing cache entry (e.g. git pull).
One way to do make cache poisoning difficult would be to make the source service set[ug]id obsrun, but of course history has shown that making a shellscript set[ug]id is generally a Bad Idea, and it still wouldn't protect against network hijacking.
So maybe the best option is to stick with per-user caching, which is of course safe. I don't think it would be too wasteful, because in most cases outside the OBS server, there is only one developer per machine, and even if there are more, they are most likely building different packages anyway. obsrun and /var/cache/obs would only be used on the build server, so they should be set up by an obs-server / obs-filesystem package or similar, not the source services. If you agree, I'll remove them from the .spec files.
When I added this caching layer to the tar_scm source service, I copied Adrian's configuration pattern from the download_files service:
# config options for this host ? if [ -f /etc/obs/services/$SERVICE ]; then . /etc/obs/services/$SERVICE fi # config options for this user ? if [ -f "$HOME"/.obs/$SERVICE ]; then . "$HOME"/.obs/$SERVICE fi
So then the server-only package would set up /etc/obs/services too. It would be nice if something automatically enabled the per-user cache though. Maybe osc could do this?
On Tue, Feb 14, 2012 at 9:22 AM, Adam Spiers aspiers@suse.com wrote:
So maybe the best option is to stick with per-user caching, which is of course safe. I don't think it would be too wasteful, because in most cases outside the OBS server, there is only one developer per machine, and even if there are more, they are most likely building different packages anyway. obsrun and /var/cache/obs would only be used on the build server, so they should be set up by an obs-server / obs-filesystem package or similar, not the source services. If you agree, I'll remove them from the .spec files.
First, I agree.
But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users.
Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think.
Claudio Freire (klaussfreire@gmail.com) wrote:
On Tue, Feb 14, 2012 at 9:22 AM, Adam Spiers aspiers@suse.com wrote:
So maybe the best option is to stick with per-user caching, which is of course safe. I don't think it would be too wasteful, because in most cases outside the OBS server, there is only one developer per machine, and even if there are more, they are most likely building different packages anyway. obsrun and /var/cache/obs would only be used on the build server, so they should be set up by an obs-server / obs-filesystem package or similar, not the source services. If you agree, I'll remove them from the .spec files.
First, I agree.
Great ;-)
But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users.
This is a cache for upstream sources only (retrieved via tar_scm / download_files source services), so the dependencies would only get cached if they are being rebuilt too.
Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think.
Sorry, I'm not sure I follow. What multiuser case are you envisioning here?
On Tue, Feb 14, 2012 at 11:32 AM, Adam Spiers aspiers@suse.com wrote:
But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users.
This is a cache for upstream sources only (retrieved via tar_scm / download_files source services), so the dependencies would only get cached if they are being rebuilt too.
Oh... so the rpm cache for dependencies uses another mechanism?
Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think.
Sorry, I'm not sure I follow. What multiuser case are you envisioning here?
Multiple users using the same machine for building of OBS packages. I've worked at at least one place where this was the norm. (because I told everybody just how great OBS is ;-) )
Claudio Freire (klaussfreire@gmail.com) wrote:
On Tue, Feb 14, 2012 at 11:32 AM, Adam Spiers aspiers@suse.com wrote:
But remember that though they'll be building different packages, many (and I mean MANY) dependencies that would be downloaded into the cache could be shared among users.
This is a cache for upstream sources only (retrieved via tar_scm / download_files source services), so the dependencies would only get cached if they are being rebuilt too.
Oh... so the rpm cache for dependencies uses another mechanism?
Yes, that's completely different - see the 'packagecachedir' config parameter in ~/.oscrc. I'm talking about a new cache just for source services which isn't even used it ...
Security takes precedence IMO, but it's not as inconsequential in the multiuser case as you may think.
Sorry, I'm not sure I follow. What multiuser case are you envisioning here?
Multiple users using the same machine for building of OBS packages. I've worked at at least one place where this was the norm.
OK, so in that scenario you are saying it's not as inconsequential as I may think - but actually I think security is pretty important, so I'm still not sure what your point was ;-)
(because I told everybody just how great OBS is ;-) )
It's pretty amazing yes. We should not forget that while we are busy coming up with ways to make Adrian more stressed ;-)
On Tue, Feb 14, 2012 at 12:41 PM, Adam Spiers aspiers@suse.com wrote:
Multiple users using the same machine for building of OBS packages. I've worked at at least one place where this was the norm.
OK, so in that scenario you are saying it's not as inconsequential as I may think - but actually I think security is pretty important, so I'm still not sure what your point was ;-)
Only that it shouldn't be pushed silently.
A warning for users might be in order if disk usage will grow considerably in that use case.
Claudio Freire (klaussfreire@gmail.com) wrote:
On Tue, Feb 14, 2012 at 12:41 PM, Adam Spiers aspiers@suse.com wrote:
Multiple users using the same machine for building of OBS packages. I've worked at at least one place where this was the norm.
OK, so in that scenario you are saying it's not as inconsequential as I may think - but actually I think security is pretty important, so I'm still not sure what your point was ;-)
Only that it shouldn't be pushed silently.
That what shouldn't be pushed? (Sorry, brained fried today ;-)
A warning for users might be in order if disk usage will grow considerably in that use case.
Yeah, well, arguably disk usage monitoring should be in place anyway ;-)
On Tue, Feb 14, 2012 at 2:45 PM, Adam Spiers aspiers@suse.com wrote:
OK, so in that scenario you are saying it's not as inconsequential as I may think - but actually I think security is pretty important, so I'm still not sure what your point was ;-)
Only that it shouldn't be pushed silently.
That what shouldn't be pushed? (Sorry, brained fried today ;-)
Well, I feel I'm reading this out of context too, because the starting message on the thread looks like it came from an on-going discussion I'm missing.
But, I'm assuming, this is something relating the "osc" tool.
So, in that case, a warning in the changelog at least? As a warning for those following the list, maybe this thread is warning enough, but for those that do not, a note in the changelog might be a good thing as well.
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
Archie Cobbs (archie.cobbs@gmail.com) wrote:
Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.
It is the easiest way, but there are also other ways with multiple spec files.
In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.
no.
So what happens? They either try to shoehorn foobar-2.1 onto 11.3, with lots of resulting build issues, or if that becomes too hard they just drop support for 11.3 or leave the build broken.
Some brave projects are willing to spawn sub-projects for each openSUSE version, e.g. Virtualization:openSUSE11.3. But this is unwieldy and hard to manage, and as a result most projects don't bother to do this.
that makes no sense usually. You can still build against DISCONTINUED:openSUSE:11.3 from same project. It is just that an absolute minority wants to support that at all.
I'm very new to the OBS, but I agree - to my inexperienced eyes, it does seem like there could be a more elegant solution.
(dreaming) Why not let each project be a simple git repo, with a branch for each repository, defaulting to 'master' if no such branch were defined?
Right, that was also my first reaction too the first time I found myself in a twisty maze of OBS repositories, all alike. Could it make sense to switch the OBS backend to git?
There is a stub for that but a lot is missing like event handling and release counter handling. And you can't use git for entire projects or even a repo for package repo, because the size of the tar balls would kill you in default settings. And git sub-projects are just the horror ...
Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge?
Adrian Schröter (adrian@suse.de) wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
Could it make sense to switch the OBS backend to git?
There is a stub for that but a lot is missing like event handling and release counter handling.
I see. Would be interested to learn more about what's missing at some point ...
And you can't use git for entire projects
Agreed, that would be a bad idea, unless each project tracked its packages via sub-modules.
or even a repo for package repo,
This is what I had in mind.
because the size of the tar balls would kill you in default settings.
git-annex would easily solve that problem.
And git sub-projects are just the horror ...
Oh, OK :-) Why don't you like them?
Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge?
Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model. It would only provide decentralization client-side (i.e. from the perspective of OBS users), but that makes sense to me anyway, since the OBS server is unavoidably centralized. Then it would allow users to visualize package branches with standard tools like gitk, submit requests would map to pull requests (à la github), and merges could also be done with standard tools like kdiff3.
On my last team which was organised around a central svn server, I used git-svn for two years and it gave me most of the advantages of decentralized development without anyone else on the team even needing to know. Then some of the other guys started getting interested, and it allowed us to collaborate in a decentralized way independently of the central svn server:
https://twiki.innerweb.novell.com/pub/PSO/GitHOWTO/_801___Screenshot.png
When's the next hackweek? ;-)
Adam Spiers (aspiers@suse.com) wrote:
Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model.
OK, so this is not a new idea - someone just pointed me at
http://en.opensuse.org/openSUSE:Build_Service_Git_Backend
What happened with that?
Am Dienstag, 14. Februar 2012, 12:45:24 schrieb Adam Spiers:
Adam Spiers (aspiers@suse.com) wrote:
Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model.
OK, so this is not a new idea - someone just pointed me at
http://en.opensuse.org/openSUSE:Build_Service_Git_Backend
What happened with that?
As I wrote in my other my mail. It is incomplete and still a lot of stuff to solve.
You can find last code in obs git in the src/backend/bs_sshgit file.
On Tuesday 14 February 2012, Adam Spiers wrote:
Adrian Schröter (adrian@suse.de) wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
Could it make sense to switch the OBS backend to git?
There is a stub for that but a lot is missing like event handling and release counter handling.
I see. Would be interested to learn more about what's missing at some point ...
And you can't use git for entire projects
Agreed, that would be a bad idea, unless each project tracked its packages via sub-modules.
or even a repo for package repo,
This is what I had in mind.
because the size of the tar balls would kill you in default settings.
git-annex would easily solve that problem.
And git sub-projects are just the horror ...
Oh, OK :-) Why don't you like them?
Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge?
Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model. It would only provide decentralization client-side (i.e. from the perspective of OBS users), but that makes sense to me anyway, since the OBS server is unavoidably centralized. Then it would allow users to visualize package branches with standard tools like gitk, submit requests would map to pull requests (à la github), and merges could also be done with standard tools like kdiff3.
Yes, git support is IMO a must have. The major advantages I see would be
- not losing commit history when sr'ing/merging or linking packages - locally doing atomic (readable) commits, pushing them squashed to OBS to avoid re-building every commit. - offline work is possible when OBS is down (which happened very often in the last time) - fetching several package clones (regardless their names) into the same working copy to speed up testing/comparing - rebasing commit history to have nice commit series to be pulled from the major projects (devel, factory etc.).
cu, Rudi
On my last team which was organised around a central svn server, I used git-svn for two years and it gave me most of the advantages of decentralized development without anyone else on the team even needing to know. Then some of the other guys started getting interested, and it allowed us to collaborate in a decentralized way independently of the central svn server:
https://twiki.innerweb.novell.com/pub/PSO/GitHOWTO/_801___Screenshot. png
When's the next hackweek? ;-)
Am Dienstag, 14. Februar 2012, 14:14:21 schrieb Ruediger Meier:
On Tuesday 14 February 2012, Adam Spiers wrote:
Adrian Schröter (adrian@suse.de) wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
Could it make sense to switch the OBS backend to git?
There is a stub for that but a lot is missing like event handling and release counter handling.
I see. Would be interested to learn more about what's missing at some point ...
And you can't use git for entire projects
Agreed, that would be a bad idea, unless each project tracked its packages via sub-modules.
or even a repo for package repo,
This is what I had in mind.
because the size of the tar balls would kill you in default settings.
git-annex would easily solve that problem.
And git sub-projects are just the horror ...
Oh, OK :-) Why don't you like them?
Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge?
Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model. It would only provide decentralization client-side (i.e. from the perspective of OBS users), but that makes sense to me anyway, since the OBS server is unavoidably centralized. Then it would allow users to visualize package branches with standard tools like gitk, submit requests would map to pull requests (à la github), and merges could also be done with standard tools like kdiff3.
Yes, git support is IMO a must have. The major advantages I see would be
- not losing commit history when sr'ing/merging or linking packages
Actually, this would be also a not acceptable regression, if you do not see anymore when you have merged requests. So, there would be a concept needed how to tag and handle reverts.
- locally doing atomic (readable) commits, pushing them squashed to OBS to avoid re-building every commit.
Oh, well, priorisation system should take care of that.
- offline work is possible when OBS is down (which happened very often in the last time)
actually, offline work (offline build) is supported meanwhile in osc. And dependency calculation is still required server side in any case, independend of the used src revisions system.
- fetching several package clones (regardless their names) into the same working copy to speed up testing/comparing
we would need that anyway in seperate build environements or we can handle the parallel build on server.
- rebasing commit history to have nice commit series to be pulled from the major projects (devel, factory etc.).
...
Do not get me wrong, I am not against an additional git backend. But there are _MANY_ of unresolved problems with that and there do not even exists concepts at all how to solve all the regressions and major problems a git backend would have.
But everybody can take of course the existing code and work on it. But the resulting code needs not to work on a single small package, but scale also for projects like openSUSE:Factory.
The api test suite may be helpfull to see _some_ of the problems when you replace the backend.
cu, Rudi
On my last team which was organised around a central svn server, I used git-svn for two years and it gave me most of the advantages of decentralized development without anyone else on the team even needing to know. Then some of the other guys started getting interested, and it allowed us to collaborate in a decentralized way independently of the central svn server:
https://twiki.innerweb.novell.com/pub/PSO/GitHOWTO/_801___Screenshot.
png
When's the next hackweek? ;-)
On Tuesday 14 February 2012, Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 14:14:21 schrieb Ruediger Meier:
On Tuesday 14 February 2012, Adam Spiers wrote:
Adrian Schröter (adrian@suse.de) wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
Could it make sense to switch the OBS backend to git?
There is a stub for that but a lot is missing like event handling and release counter handling.
I see. Would be interested to learn more about what's missing at some point ...
And you can't use git for entire projects
Agreed, that would be a bad idea, unless each project tracked its packages via sub-modules.
or even a repo for package repo,
This is what I had in mind.
because the size of the tar balls would kill you in default settings.
git-annex would easily solve that problem.
And git sub-projects are just the horror ...
Oh, OK :-) Why don't you like them?
Or at least build a git-obs bridge, in a similar manner to the existing git-svn bridge?
Of course I'm biased because this is my idea ;-) but I think that git-obs would be a cool step towards a more decentralized model. It would only provide decentralization client-side (i.e. from the perspective of OBS users), but that makes sense to me anyway, since the OBS server is unavoidably centralized. Then it would allow users to visualize package branches with standard tools like gitk, submit requests would map to pull requests (à la github), and merges could also be done with standard tools like kdiff3.
Yes, git support is IMO a must have. The major advantages I see would be
- not losing commit history when sr'ing/merging or linking packages
Actually, this would be also a not acceptable regression, if you do not see anymore when you have merged requests. So, there would be a concept needed how to tag and handle reverts.
Of course always "git merge --no-ff" into factory/master.
- locally doing atomic (readable) commits, pushing them squashed to
OBS to avoid re-building every commit.
Oh, well, priorisation system should take care of that.
My major point here is that changes across different topics should never be mixed into the same commit. But svn-like VCS leads to do it the bad way. Submit requests could be reviewed much easier if you see all the atomic commits behind a huge submit-request.
- offline work is possible when OBS is down (which happened very
often in the last time)
actually, offline work (offline build) is supported meanwhile in osc.
Is it possible to commit local only?
And dependency calculation is still required server side in any case, independend of the used src revisions system.
- fetching several package clones (regardless their names) into the
same working copy to speed up testing/comparing
we would need that anyway in seperate build environements or we can handle the parallel build on server.
- rebasing commit history to have nice commit series to be pulled
from the major projects (devel, factory etc.).
...
Do not get me wrong, I am not against an additional git backend. But there are _MANY_ of unresolved problems with that and there do not even exists concepts at all how to solve all the regressions and major problems a git backend would have.
But everybody can take of course the existing code and work on it. But the resulting code needs not to work on a single small package, but scale also for projects like openSUSE:Factory.
The api test suite may be helpfull to see _some_ of the problems when you replace the backend.
For now I just do "git init" within ocs working copies. It does already much of what I need allthough it can be confusing. An intermediate next step could be to improve the client side only by providing a git-osc similar to git-svn. Finally having git backend on OBS side someday would be really nice.
cu, Rudi
On my last team which was organised around a central svn server, I used git-svn for two years and it gave me most of the advantages of decentralized development without anyone else on the team even needing to know. Then some of the other guys started getting interested, and it allowed us to collaborate in a decentralized way independently of the central svn server:
https://twiki.innerweb.novell.com/pub/PSO/GitHOWTO/_801___Screens hot.
png
When's the next hackweek? ;-)
Am Dienstag, 14. Februar 2012, 15:18:32 schrieb Ruediger Meier:
On Tuesday 14 February 2012, Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 14:14:21 schrieb Ruediger Meier:
On Tuesday 14 February 2012, Adam Spiers wrote:
Adrian Schröter (adrian@suse.de) wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
...
- not losing commit history when sr'ing/merging or linking packages
Actually, this would be also a not acceptable regression, if you do not see anymore when you have merged requests. So, there would be a concept needed how to tag and handle reverts.
Of course always "git merge --no-ff" into factory/master.
that is not a solution.
- locally doing atomic (readable) commits, pushing them squashed to
OBS to avoid re-building every commit.
Oh, well, priorisation system should take care of that.
My major point here is that changes across different topics should never be mixed into the same commit. But svn-like VCS leads to do it the bad way. Submit requests could be reviewed much easier if you see all the atomic commits behind a huge submit-request.
Frankly, I see this really as a minor thing during packaging work.
If you are unsure about your work, you branch anyway before submitting.
- offline work is possible when OBS is down (which happened very
often in the last time)
actually, offline work (offline build) is supported meanwhile in osc.
Is it possible to commit local only?
No. But again, I think this is a minor thing. It is way more important to have offline builds to be able to do packaging work.
And dependency calculation is still required server side in any case, independend of the used src revisions system.
- fetching several package clones (regardless their names) into the
same working copy to speed up testing/comparing
we would need that anyway in seperate build environements or we can handle the parallel build on server.
- rebasing commit history to have nice commit series to be pulled
from the major projects (devel, factory etc.).
...
Do not get me wrong, I am not against an additional git backend. But there are _MANY_ of unresolved problems with that and there do not even exists concepts at all how to solve all the regressions and major problems a git backend would have.
But everybody can take of course the existing code and work on it. But the resulting code needs not to work on a single small package, but scale also for projects like openSUSE:Factory.
The api test suite may be helpfull to see _some_ of the problems when you replace the backend.
For now I just do "git init" within ocs working copies. It does already much of what I need allthough it can be confusing. An intermediate next step could be to improve the client side only by providing a git-osc similar to git-svn. Finally having git backend on OBS side someday would be really nice.
Well, if that works for you that is fine. But using git as repo is a complete different level of problems. Just because git offers a feature for you it does not mean it offers all the features (revision counting, on-the-fly-merge, revision tracking, shadows sources and so on) the obs needs.
Anyway, since people always only say that git would solve everything but no one works on it, I am stopping now here ;)
Feel free to work on it and I promise we will help you run into problems...
bye adrian
On Tuesday 14 February 2012, Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 15:18:32 schrieb Ruediger Meier:
On Tuesday 14 February 2012, Adrian Schröter wrote:
Am Dienstag, 14. Februar 2012, 14:14:21 schrieb Ruediger Meier:
On Tuesday 14 February 2012, Adam Spiers wrote:
Adrian Schröter (adrian@suse.de) wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
...
- not losing commit history when sr'ing/merging or linking
packages
Actually, this would be also a not acceptable regression, if you do not see anymore when you have merged requests. So, there would be a concept needed how to tag and handle reverts.
Of course always "git merge --no-ff" into factory/master.
that is not a solution.
Oh, then I haven't understood the problem.
- locally doing atomic (readable) commits, pushing them
squashed to OBS to avoid re-building every commit.
Oh, well, priorisation system should take care of that.
My major point here is that changes across different topics should never be mixed into the same commit. But svn-like VCS leads to do it the bad way. Submit requests could be reviewed much easier if you see all the atomic commits behind a huge submit-request.
Frankly, I see this really as a minor thing during packaging work.
If you are unsure about your work, you branch anyway before submitting.
That's the way I do it but it doesn't change the fact that currently branching is a very slow remote operation, check out again, switching working copy, etc. And moreover after sr the commit history is lost,
- offline work is possible when OBS is down (which happened
very often in the last time)
actually, offline work (offline build) is supported meanwhile in osc.
Is it possible to commit local only?
No. But again, I think this is a minor thing. It is way more important to have offline builds to be able to do packaging work.
It might be a minor thing from OBS admin's view. From developers view I wouldn't leave the room as long as my working copy is dirty. And I wouldn't even start to work if my VCS does not have full functionality yet. That's why I _workaround_ with "git init". Just pity that I can't save my local git history directly on OBS so I need to hope that I don't make mistakes when manually synchronizing my work between local git and remote OBS.
And dependency calculation is still required server side in any case, independend of the used src revisions system.
- fetching several package clones (regardless their names) into
the same working copy to speed up testing/comparing
we would need that anyway in seperate build environements or we can handle the parallel build on server.
- rebasing commit history to have nice commit series to be
pulled from the major projects (devel, factory etc.).
...
Do not get me wrong, I am not against an additional git backend. But there are _MANY_ of unresolved problems with that and there do not even exists concepts at all how to solve all the regressions and major problems a git backend would have.
But everybody can take of course the existing code and work on it. But the resulting code needs not to work on a single small package, but scale also for projects like openSUSE:Factory.
The api test suite may be helpfull to see _some_ of the problems when you replace the backend.
For now I just do "git init" within ocs working copies. It does already much of what I need allthough it can be confusing. An intermediate next step could be to improve the client side only by providing a git-osc similar to git-svn. Finally having git backend on OBS side someday would be really nice.
Well, if that works for you that is fine. But using git as repo is a complete different level of problems. Just because git offers a feature for you it does not mean it offers all the features (revision counting, on-the-fly-merge, revision tracking, shadows sources and so on) the obs needs.
Anyway, since people always only say that git would solve everything but no one works on it, I am stopping now here ;)
Feel free to work on it and I promise we will help you run into problems...
Hey, I don't want to force you moving OBS to git. Just mentioned that it would be a real improvement (at least for the packagers who care as much about history and commit style like me).
cu,Rudi
Ruediger Meier (sweet_f_a@gmx.de) wrote:
On Tuesday 14 February 2012, Adrian Schröter wrote:
Is it possible to commit local only?
No. But again, I think this is a minor thing. It is way more important to have offline builds to be able to do packaging work.
It might be a minor thing from OBS admin's view. From developers view I wouldn't leave the room as long as my working copy is dirty. And I wouldn't even start to work if my VCS does not have full functionality yet. That's why I _workaround_ with "git init". Just pity that I can't save my local git history directly on OBS so I need to hope that I don't make mistakes when manually synchronizing my work between local git and remote OBS.
My habits are the same as yours, Rudi. I guess Adrian's point is that normally the changes required within the osc working directory are tiny and really simple (e.g. update .tar.bz2 / .changes / Version number in .spec file). Although when working on the tests for obs-service-tar_scm, I had to develop the full test suite inside this directory, so I had to do 'git init' otherwise it would have been a disaster.
Hey, I don't want to force you moving OBS to git. Just mentioned that it would be a real improvement (at least for the packagers who care as much about history and commit style like me).
Trying to summarize a few different threads of discussion from the last few days:
- everyone seems generally agreed that, if (and only if!) the implementation challenges could be solved, having git frontend and backends for OBS would bring a lot of advantages (these are very nicely documented at http://en.opensuse.org/openSUSE:Build_Service_Git_Backend)
- there are a LOT of challenges to overcome before this could happen, and some still have no known solution according to Adrian
- some really good work was started in 2009 as documented on the wiki page
Remaining questions:
1. Is the *outcome* of the GSoC 2009 project documented anywhere?
2. Is anyone still working on it?
3. Is bsgit still usable? Doesn't seem to have changed since 2009.
I'm also guessing noone has spare time to dedicate to such a big project right now. So my suggestion is to take a "divide and conquer" or "softly softly" approach:
- establish a central location (e.g. the wiki) for documenting and working on the existing problems
- ensure that this location contains past work, current status, and future work (it doesn't have to be polished, just reasonably accurate)
- classify future work items into two separate buckets:
+ problems we know how to solve, but which haven't been done yet + problems for which there is still no solution
(BTW this last item is particularly important, otherwise people could waste time implementing something which might not work in the real world e.g. due to scalability issues or some of the other concerns Adrian already mentioned.)
If we had this documentation then people would be able to choose a small chunk of work whenever they have a bit of spare time, and then hopefully we could maintain a small amount of momentum.
So if noone has any objections, I am happy to start working on updating the wiki - but then I would need some help, because with the exception of what was recently stated on these lists, I am missing a lot of information about known problems with moving to git.
On Tue, Feb 14, 2012 at 5:19 AM, Adrian Schröter adrian@suse.de wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
Archie Cobbs (archie.cobbs@gmail.com) wrote:
Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.
It is the easiest way, but there are also other ways with multiple spec files.
In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.
no.
So what happens? They either try to shoehorn foobar-2.1 onto 11.3, with lots of resulting build issues, or if that becomes too hard they just drop support for 11.3 or leave the build broken.
Some brave projects are willing to spawn sub-projects for each openSUSE version, e.g. Virtualization:openSUSE11.3. But this is unwieldy and hard to manage, and as a result most projects don't bother to do this.
that makes no sense usually. You can still build against DISCONTINUED:openSUSE:11.3 from same project. It is just that an absolute minority wants to support that at all.
Adrian I'm sure you're getting tired of this conversation thread, and me too.
I'm am going to give up trying to suggest solutions because I don't have the knowledge that you do and you can see all the flaws in my naive ideas.
So let me just describe the problem one last time and ask you to please suggest the right answer.
Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.
Also, mapserver does not exist in any of the DISCONTINUED:openSUSE:11.3 repos, or Evergreen, or anywhere else.
So that's the problem: I need to be able to build and support servers that last more than 18 months and it's become practically impossible.
And I really don't think I am in a "small minority" in that need.
I love openSUSE and the OBS. Unfortunately, while the idea of creating OBS was a brilliant one, the idea of forcing openSUSE to live within its constraints has this bad unintended side-effect.
Adrian please use your wisdom and help think of how the problem I've described might be improved.
Thanks, -Archie
Am Dienstag, 14. Februar 2012, 10:34:44 schrieb Archie Cobbs:
On Tue, Feb 14, 2012 at 5:19 AM, Adrian Schröter adrian@suse.de wrote:
Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:
Archie Cobbs (archie.cobbs@gmail.com) wrote:
Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.
It is the easiest way, but there are also other ways with multiple spec files.>
In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.
no.
So what happens? They either try to shoehorn foobar-2.1 onto 11.3, with lots of resulting build issues, or if that becomes too hard they just drop support for 11.3 or leave the build broken.
Some brave projects are willing to spawn sub-projects for each openSUSE version, e.g. Virtualization:openSUSE11.3. But this is unwieldy and hard to manage, and as a result most projects don't bother to do this.
that makes no sense usually. You can still build against DISCONTINUED:openSUSE:11.3 from same project. It is just that an absolute minority wants to support that at all.
Adrian I'm sure you're getting tired of this conversation thread, and me too.
I'm am going to give up trying to suggest solutions because I don't have the knowledge that you do and you can see all the flaws in my naive ideas.
So let me just describe the problem one last time and ask you to please suggest the right answer.
Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.
It was removed because it is not anymore maintained. And as the Application:Geo maintainer I can tell you that I will not spend the additional work to do so in future. (Keep in mind that maintaining for old distros costs way more time then for current ones).
If you need that particular package, then branch the sources and maintain it in your project. But you can't expect other to do your work.
period adrian
On Tue, Feb 14, 2012 at 11:04 AM, Adrian Schröter adrian@suse.de wrote:
Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.
It was removed because it is not anymore maintained. And as the Application:Geo maintainer I can tell you that I will not spend the additional work to do so in future.
(Keep in mind that maintaining for old distros costs way more time then for current ones).
If you need that particular package, then branch the sources and maintain it in your project. But you can't expect other to do your work.
That is understood. I appreciate the maintainers' efforts and I'm not asking anyone to continue maintain something they don't want to.
Rather, just don't delete it... OR, better yet please suggest a solution to the dilemma I described in the previous email.
Really, I'm simply asking for your creative guidance and suggestions. I'm not the expert (you are of course).
Or are you implying that openSUSE will never be a practical choice for the >18 month crowd?
Thanks, -Archie
-- Archie L. Cobbs
On Tue, Feb 14, 2012 at 11:19:35AM -0600, Archie Cobbs wrote: [ 8< ]
Or are you implying that openSUSE will never be a practical choice for the >18 month crowd?
There is the openSUSE evergreen approach. It has a page in the wiki. I suggest to join the efforts Wolfgang and others are focusing on.
The life time of openSUSE 11.3 had been announced from the beginning.
We also need to free the resources openSUSE 11.3 based builds consumed.
And there is an alternative. Go with SUSE Linux Enterprise based products and you'll get something going much, much longer.
Cheers,
Lars
On Tue, Feb 14, 2012 at 12:19 PM, Archie Cobbs archie.cobbs@gmail.com wrote:
On Tue, Feb 14, 2012 at 11:04 AM, Adrian Schröter adrian@suse.de wrote:
Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.
It was removed because it is not anymore maintained. And as the Application:Geo maintainer I can tell you that I will not spend the additional work to do so in future.
(Keep in mind that maintaining for old distros costs way more time then for current ones).
If you need that particular package, then branch the sources and maintain it in your project. But you can't expect other to do your work.
That is understood. I appreciate the maintainers' efforts and I'm not asking anyone to continue maintain something they don't want to.
Rather, just don't delete it... OR, better yet please suggest a solution to the dilemma I described in the previous email.
Really, I'm simply asking for your creative guidance and suggestions. I'm not the expert (you are of course).
Or are you implying that openSUSE will never be a practical choice for the >18 month crowd?
Thanks, -Archie
Archie,
If you could do the following, would it work for you?
At the EOL of a distro:
# clean the repo cache's, this works today I think. zypper clean --all
# rebuild the metadata, this works today I think. zypper refresh --force
# populate the cache's with a copy of all the packages you have installed, this is new functionality I think zypper install --force --download-only *
Then burn /etc/zypp/ and /var/cache/zypp to DVD (or whatever)
Then if you need to recreate a server, its restore those 2 directories and use
zypper --no-remote
==> I don't know if that would put to much load on OBS, or how hard it would be to add the missing zypper functionality, but it seems reasonably doable.
Greg
On Tue, Feb 14, 2012 at 1:07 PM, Greg Freemyer greg.freemyer@gmail.com wrote:
If you could do the following, would it work for you?
At the EOL of a distro:
# clean the repo cache's, this works today I think. zypper clean --all
# rebuild the metadata, this works today I think. zypper refresh --force
# populate the cache's with a copy of all the packages you have installed, this is new functionality I think zypper install --force --download-only *
Then burn /etc/zypp/ and /var/cache/zypp to DVD (or whatever)
Then if you need to recreate a server, its restore those 2 directories and use
zypper --no-remote
==> I don't know if that would put to much load on OBS, or how hard it would be to add the missing zypper functionality, but it seems reasonably doable.
Yes, something like that would be a good start. Thanks for offering a constructive idea. Still, it seems like an unfortunate hack...
Why not set up a new server http://download-discontinued.opensuse.org/, where right when openSUSE X.Y is EOL, all the openSUSE X.Y repos are moved there. Once moved, they would no longer be maintained, but would still be available for download. They would just be a static snapshot.
Then the original download.opensuse.org could simply send back 302 Redirect responses for the EOL'd repos to fetch to http://download-discontinued.opensuse.org/ instead.
This would only cost a few gigabytes, one simple copy operation every 8 months, and zero additional packager maintenance burden.
Like I previously mentioned, there is a basic disconnect here caused by the "port" of openSUSE to OBS. Evidence for this disconnect is visible in the fact that openSUSE 11.3 itself is still available for download on download.opensuse.org, yet the openSUSE 11.3 OBS repos are not.
This solution would simply remedy that disconnect. It seems very easy and it would solve a big problem for some of us.
-Archie
Archie Cobbs wrote:
[...] Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.
Also, mapserver does not exist in any of the DISCONTINUED:openSUSE:11.3 repos, or Evergreen, or anywhere else.
So that's the problem: I need to be able to build and support servers that last more than 18 months and it's become practically impossible.
I really don't understand how you managed to get into that situation. Was the fact that openSUSE gets updates for 18 months and that 11.3 is going EOL in January 2012 not communicated prominently enough? Did you miss the discontinuation reminder that was sent six weeks before the fact?
At this point you should bite the bullet and upgrade to 11.4 or 12.1 ASAP. Set a reminder in your calendar to prepare for the next distro upgrade in time.
cu Ludwig
On Wed, Feb 15, 2012 at 5:44 AM, Ludwig Nussel ludwig.nussel@suse.de wrote:
At this point you should bite the bullet and upgrade to 11.4 or 12.1 ASAP. Set a reminder in your calendar to prepare for the next distro upgrade in time.
...or have mirrored the repo long ago.
On Wed, Feb 15, 2012 at 2:44 AM, Ludwig Nussel ludwig.nussel@suse.de wrote:
Right now it is impossible to (re)build our openSUSE 11.3-based server because, to take just ONE EXAMPLE, the mapserver package is not available for 11.3. This is because the Application:Geo/openSUSE_11.3 repo was destroyed.
Also, mapserver does not exist in any of the DISCONTINUED:openSUSE:11.3 repos, or Evergreen, or anywhere else.
So that's the problem: I need to be able to build and support servers that last more than 18 months and it's become practically impossible.
I really don't understand how you managed to get into that situation. Was the fact that openSUSE gets updates for 18 months and that 11.3 is going EOL in January 2012 not communicated prominently enough? Did you miss the discontinuation reminder that was sent six weeks before the fact?
It's 100% my own fault, I agree with that.
My mistake was to believe that "EOL" meant merely "no longer supported" instead of "deleted immediately".
And I'm not describing the problem here in order to assign blame to anyone.
Rather I was hoping that we can discuss how things might work better for people who want to use openSUSE for longer than 18 months, without imposing an additional burden on package maintainers.
I've offered an idea and would appreciate feedback on it.
Thanks, -Archie
Archie Cobbs wrote:
[...] Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.
In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.
First and foremost get the package into the distro instead of building it in some random repo. The whole point of the distro is to be a collection of packages that work together.
Secondly, you can have different versions of foobar in the same project by naming the source directories e.g. foobar and a foobar.openSUSE_xy. Only the latter would be build enabled for openSUSE xy while the former builds for everything else.
cu Ludwig
On Tue, Feb 14, 2012 at 2:40 AM, Ludwig Nussel ludwig.nussel@suse.de wrote:
Archie Cobbs wrote:
[...] Why? First, it is worth observing that the very nature of OBS makes it difficult to pursue that goal. Because in OBS, for any project/package there is only one spec file - and therefore package version - for ALL repositories.
In other words, it would be impossible for a maintainer to configure a package to build foobar-1.2 on openSUSE 11.3 but foobar-2.1 on openSUSE 12.1.
First and foremost get the package into the distro instead of building it in some random repo. The whole point of the distro is to be a collection of packages that work together.
Agreed.
Secondly, you can have different versions of foobar in the same project by naming the source directories e.g. foobar and a foobar.openSUSE_xy. Only the latter would be build enabled for openSUSE xy while the former builds for everything else.
That works for one project but is impractical as a general solution ... it would require an explicit action (and new source directory) for every package in every OBS project every 8 months.
-Archie
On Fri, 27 Jan 2012 10:24:06 -0500, Patrick Shanahan wrote:
off-base Novell != openSUSE
Well, let's be clear here. When talking "Novell", I think it's reasonable to say that what's actually meant is SUSE, or by extension Attachmate at this stage.
While, as I read the conversations on the mail lists, consideration is given to Novell's business model but not *defining* the path of openSUSE. Novell has no "enforcement mechanism" in place. You are grasping straws and causing confusion, ie: spreading fud.
No, but OBS is, I think (like Studio) not entirely openSUSE but a mix of SUSE and openSUSE, and there are some joint goals and there are some non- common goals.
And the fact that those services are hosted by SUSE (or whatever name you call the business that owns the hardware) means that they probably do have some say about things that drive into their line of business and revenue generation.
Jim
On Fri, 27 Jan 2012 09:13:00 -0600, Archie Cobbs wrote:
Your #5 is:
"That means that when resources are constrained, something gets clipped, and the logical starting place is to start with the oldest stuff."Sounds good to me! So let's look at the facts:
openSUSE 11.3: 1.5 years old, and is a SUSE distribution RHEL 4: 7 years old, and is not a SUSE distributionMy simple question is: why openSUSE 11.3 before (for example) RHEL 4? What are the underlying priorities that resulted in that choice?
I couldn't tell you since I'm not privy to the business information.
But at a guess, it's not based on age but number of releases. RHEL6 IIRC is the current release, and for customers running older releases, SUSE has an incentive to support them because they would like nothing better than to migrate those RH customers to SLES.
By including RHEL4/5/6 in OBS, that lets custom packages those RHEL customers are building to be built cross-distribution making migration easier.
But that's just a guess based on what I know/knew from when I was at Novell.
Jim
Am Donnerstag, 26. Januar 2012, 15:04:25 schrieb Claudio Freire:
On Thu, Jan 26, 2012 at 2:47 PM, Archie Cobbs archie.cobbs@gmail.com
wrote:
We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
Just add the DISCONTINUED repo to your home, and all is fine.
Just a question... do the DISCONTINUED repos have all updates applied?
The DISCONTINUED:...:Update have.
OBS has always done that (or at least for quite a while)
All you have to do is go in to your project conf xml and add the DISCONTINUED_openSUSE_11.3_Update_standard build target.
In a few months you will have to do the same with 11.4 etc... Once they go discontinued, they don't change any more and you don't have to worry about them disappearing any more.
I actually use the web interface to edit the xml because the web interface for adding repositories is buggy and doesn't display all the targets that actually are available. But looking at the values that it created in the xml you can extrapolate the possible names for the targets it didn't display, and luckily they worked.
So, I don't know the OSC command way to do this which would be a better and more reliable way to document a procedure, but here is the web ui way:
Log in to obs, my projects, click a project (home:foo) Click the Advanced tab Then click the Meta tab that appears further to the right.
Insert a repository stanza like this:
<repository name="DISCONTINUED_openSUSE_11.2_Update_standard"> <path repository="standard" project="DISCONTINUED:openSUSE:11.2:Update"/> <arch>x86_64</arch> <arch>i586</arch> </repository>
Only 11.3
Except, my home repo still shows a regular 11.3, maybe the purge is currently in progress and just hasn't reached my project?
My xml still includes:
<repository name="openSUSE_11.3"> <path repository="standard" project="openSUSE:11.3:Update"/> <arch>i586</arch> <arch>x86_64</arch> </repository>
So, when my 11.3 repo disappears I'll go in here and edit or create
<repository name="DISCONTINUED_openSUSE_11.3_Update_standard"> <path repository="standard" project="DISCONTINUED:openSUSE:11.3:Update"/> <arch>x86_64</arch> <arch>i586</arch> </repository>
The way I got those magic values initially was from using the repositories tab and the "add repostitories" link there, then "pick one via advanced interface"
Then enter "open" or "suse" or "DISCONTINUED" into the "Repositires:" box. It will generate an (incomplete) list of various suse and opensuse repos. (If nothing happens, just wait a few seconds, it's slow sometimes.)
You want "DISCONTINUED_openSUSE_11.3_Update_standard"
Except that doesn't seem to exist yet.
Mine still just shows openSUSE_11.3
Anyways, select any one, even if the version you want doesn't show, pick 11.1 or 11.2 etc, then hit "add repository"
Then hit the Advanced tab again, then the Meta tab, and edit the xml directly. You will see the new repository in there, just try manually editing the 11.2 or 11.1 to 11.3.
And finally, if 11.3 is undergoing transition right now, then none of this may work for 11.3 specifically right at this moment. You may have to wait a day or so and try it then. Other repos will work. You could add 11.2 just to go through the process and verify that you are doing it right, even if you really want 11.3 and 11.3 isn't working right now.
It's a drag for people trying to get work done and who need to support production machines I agree 100%.
But, still, maintaining one spec file and one set of sources on OBS and having to dink around with the disappearing build targets and the slightly buggy web ui and the swiss cheese osc documentation is still better than building everything myself on all the different boxes, even with rpmbuild and maintaining my own install server to re-use rpms once built.
-- bkw
On 1/26/2012 12:47 PM, Archie Cobbs wrote:
Holy crap.
I just realized that OBS has blown away ALL 11.3 repos, including my home directory, not just openSUSE:Tools.
Argggh... trying to remain philosophical here...
We have a bunch of mission critical machines running openSUSE 11.3. Why? Because one of the attractive features of openSUSE is that it is very stable and runs great for a long time.
But now all of these machines are essentially unsupportable (and unreproducible), until we force them through an upgrade process that creates risk.
So the aforementioned long term stability of openSUSE has just been invalidated as a feature!
The openSUSE community is not just a bunch of Linux kids who all like to live on the bleeding edge. It's used for serious applications all over the place. To some of you folks 11.3 may seem like ancient history but in my world it's chugging along nicely. It's only been out for 18 months for goodness sake!
OK, I can accept that I'm in the minority. So what is the right answer then for me? I guess Tumbleweed is supposed to be the solution to this problem?
In any case, here is one thing I still don't understand: will someone please explain to me why RHEL 4, released 7 years ago, is more important to the openSUSE community than openSUSE 11.3, released 18 months ago?
-Archie
On Tue, Jan 24, 2012 at 1:03 PM, Archie Cobbsarchie.cobbs@gmail.com wrote:
On Jan 24, 2012, at 8:22 AM, Bryen M Yunashkosuserocks@bryen.com wrote:
On Tue, 2012-01-24 at 08:13 -0600, Archie Cobbs wrote:
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
Do others not agree?
I'm going to assume that the EOL'ed repos get dropped due to storage conservation reasons. (only an assumption.) If that is the case, what do you propose is the length of time such repos should exist?
Longer than (for example) RHEL, which was first released seven years ago... ?
-- Archie L. Cobbs
On Thu, Jan 26, 2012 at 3:50 PM, Brian K. White brian@aljex.com wrote:
In a few months you will have to do the same with 11.4 etc... Once they go discontinued, they don't change any more and you don't have to worry about them disappearing any more.
Perhaps an extended support version should be appointed for every major version. To avoid this issue, and to appease the server folks. Which I would imagine is an important enough endeavor.
Perhaps the last minor of every major version should enjoy, if not extended *support*, at least extended *presence* in OBS.
So perhaps 11.4 shouldn't be phased out of OBS as soon as it reaches EOL. Maybe someone will volunteer for maintenance duties even, who knows.
Am Donnerstag, 26. Januar 2012, 17:29:43 schrieb Claudio Freire:
On Thu, Jan 26, 2012 at 3:50 PM, Brian K. White brian@aljex.com wrote:
In a few months you will have to do the same with 11.4 etc... Once they go discontinued, they don't change any more and you don't have to worry about them disappearing any more.
Perhaps an extended support version should be appointed for every major version. To avoid this issue, and to appease the server folks. Which I would imagine is an important enough endeavor.
Perhaps the last minor of every major version should enjoy, if not extended *support*, at least extended *presence* in OBS.
So perhaps 11.4 shouldn't be phased out of OBS as soon as it reaches EOL. Maybe someone will volunteer for maintenance duties even, who knows.
check evergreen project, it still builds againt DISCONTINUED:openSUSE:11.1
As usual, it is just a matter of work. Reach out to Wolfgang Rosenauer if you want to help 11.1 or any other DISCONTINUED distro.
* Claudio Freire klaussfreire@gmail.com [01-26-12 15:30]:
Perhaps an extended support version should be appointed for every major version. To avoid this issue, and to appease the server folks. Which I would imagine is an important enough endeavor.
Perhaps the last minor of every major version should enjoy, if not extended *support*, at least extended *presence* in OBS.
Well, there is *no* major/minor version of openSUSE and has not been for as long as I can remember. In spite of the dot numbers, *all* versions of openSUSE are *major*. In fact the published version numbers were changed effective 12.1 to always start with ##.1 to ensure the public that the issue was not a "first major changed" version.
That apparently has failed, at least in this instance.
Please feel informed. Voluminous discussion about major/minor numbering schemes for openSUSE may be viewed in the archives and, on request, a pointer will be provided.
On Thu, Jan 26, 2012 at 5:59 PM, Patrick Shanahan paka@opensuse.org wrote:
That apparently has failed, at least in this instance.
Please feel informed. Voluminous discussion about major/minor numbering schemes for openSUSE may be viewed in the archives and, on request, a pointer will be provided.
Already feeling the information flowing in :-)
On Thu, Jan 26, 2012 at 05:29:43PM -0300, Claudio Freire wrote:
On Thu, Jan 26, 2012 at 3:50 PM, Brian K. White brian@aljex.com wrote:
In a few months you will have to do the same with 11.4 etc... Once they go discontinued, they don't change any more and you don't have to worry about them disappearing any more.
Perhaps an extended support version should be appointed for every major version. To avoid this issue, and to appease the server folks. Which I would imagine is an important enough endeavor.
http://www.suse.com/products/server/ there you get all you're requesting. And if you need you get extra years of support and there are partners available all around the world.
Well this SUSE Linux Enterprise (SLE) advertisement might be as off topic as the complaiin about the short openSUSE lifetime¹ was. :)
Perhaps the last minor of every major version should enjoy, if not extended *support*, at least extended *presence* in OBS.
Why? SLE is available as a build target.
So perhaps 11.4 shouldn't be phased out of OBS as soon as it reaches EOL. Maybe someone will volunteer for maintenance duties even, who knows.
In many years we're maintaining old Samba versions for older products we've seen less than five external contributions. That was said to stress how likely it will be that someone will volunteer to maintain a huge amount of packages. That's a lot of work.
And to all the guys complainimg again and again about how good all had been in the past: Please read once again http://lists.openSUSE.org/opensuse-factory/2011-11/msg00471.html
Cheers,
Lars
¹ http://en.openSUSE.org/Lifetime
On 24/01/12 11:13, Archie Cobbs wrote:
OK forget zypper and openSUSE:Tools for the moment...
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
They should, to save a significant amount of build resources.
Am Dienstag, 24. Januar 2012, 08:13:16 schrieb Archie Cobbs:
OK forget zypper and openSUSE:Tools for the moment...
What I'm simply trying to say is: just because 11.3 is itself EOL, that doesn't mean OBS projects should start dropping the 11.3 repo right away.
The maintainers can build against DISCONTINUED:openSUSE:11.3 instead. If they don't we free the resources (storage for mirrors, on our servers and build power). So they can be used for more constructive work than just old build jobs no maintainer cares about anymore.
bye adrian
Do others not agree?
-Archie
On Tue, Jan 24, 2012 at 3:27 AM, Adrian Schröter adrian@suse.de wrote:
Am Montag, 23. Januar 2012, 20:18:49 schrieb Archie Cobbs:
I noticed that openSUSE:Tools has dropped its 11.3 repo already.
I understand 11.3 is EOL'd, but it seems like Tools repo should be special, as it contains zypper -- the tool that lets you upgrade.
No, it was never part of that repo.
I understand that EOL means no longer "community supported" - that's fine.. but it seems to me that "community supported" is a completely different concept than "exists as a repo in a project".
After all, openSUSE:Tools has RHEL 4 and all these other non-SUSE repos... are those distributions "community supported" by the openSUSE project??
So I don't understand the rush to remove the repo.
Needless to say, I still have stable 11.3 systems around that I'm not ready to upgrade just yet...
Thanks, -Archie
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- Archie L. Cobbs
buildservice@lists.opensuse.org
-
Adam Spiers -
Adrian Schröter -
Archie Cobbs -
Brian K. White -
Bryen M Yunashko -
Claudio Freire -
Cristian Rodríguez -
Greg Freemyer -
Jim Henderson -
Jos Poortvliet -
Lars Müller -
Ludwig Nussel -
Malcolm -
Marcus Meissner -
Patrick Shanahan -
Ruediger Meier -
Stephan Kulow