On Thu, Sep 21, 2006 at 04:41:06PM -0300, James Oakley wrote:
On Thursday 21 September 2006 3:57 pm, Robert Schiele wrote:
On Thu, Sep 21, 2006 at 02:21:11PM -0300, James Oakley wrote:
If you also build packages for packages that are not under an OSS license or for a distribution that is not included, you cannot use the build service in a reasonable way because the public server does not allow them
That's a very small minority of packages. That's no reason to shun it altogether.
Whether this is a minority of packages depends on what you are working on. But even if it is a minority I don't want to use two different tool sets.
and you can't set-up a private one because parts of the build service itself are proprietary software.
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
I an not sure whether it was ever really promised or not. It is just that I expected Novell to use an open development model when they announced _open_SUSE but aparently I was wrong and this is not what they wanted. What we have now is public test versions, a black-box build system and some communication channels. Those things are all nice and actually it is totally legitimate for Novell to open stuff whenever they like but what they are currently doing is definitely not what I would consider _open_ and thus the "open" in openSUSE seems to be missleading in my opinion.
Thus it generally makes more sense for such packagers to use their own build system instead and invest their time there.
So we all have private build systems that we don't publish the source for? Yes, I'm guilty of that myself, having built multiple systems...
That's exactly how it will work in my opinion until someone provides a system that is really open and does provide a new value.
What if we started in on a BS-compatible backend? I'll have some time next week to start in. Is anybody else interested in such a thing?
Well, I _had_ some big interest in integrating know-how from a project I am involved in into an open build system and then use this as a base for the project. Since the build service did not seem to become that open system we now have reached a level where switching to what the buildservice currently provides would be a big regression for us. So building a BS-compatible backend would be of some limited interest to me at the very moment. Since I am currently in a phase of changing employer, it might happen that this changes with the interest of my future employer.
Isn't this the point of the buildservice? What's the problem?
Communication problems are always a social problem in the first place. Tools can only provide some assistance here. If someone really designed the build service as a solution for _this_ problem then he actually has no clue about the problem.
We have this mailing list, which we didn't have before, so we're actually talking.
Yes, that's one step forward.
What do you think would need to change in the buildservice?
I didn't want to change anything with what I said here but wanted to say that a _tool_ does not _solve_ this problem, however you design it.
That's fine, I use your Amarok builds. However, it would be nice to be able to subscribe to an "Amarok" repository and not worry about something I don't want sneaking in.
Some tools (e.g. YaST) allow to install single packages with their dependencies without the need to install _everything_ in a repository.
Yes, but I'm talking about the effects of apt/smart/yum/rug *upgrade*, which will update everything it sees.
Ok, but then this is obviously not the right way to use his repository (as well as mine). For my repository the philosophy is quite simple: Everything I build and can be published will be put into the repository. If someone likes it he could use it, if he does not like it he should skip this package. I am open to suggestions about packaging style or things like that but I might have reasons not to implement them. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."