On 12/02/2009 02:09 PM, Adrian Schröter wrote:

Am Mittwoch, 2. Dezember 2009 14:06:42 schrieb Wolfgang Rosenauer:

...

Hi,

I've raised that issue long time ago already but there was no real outcome IIRC.

As I'm managing a a popular repository which should be kept as stable and reliable as possible I turning publishing off when I prepare a new update package. I do that even before upstream released the update officially to be able to release it at about the same time. Now as the repo is popular there are people linking to packages from there but in their repos publishing is not disabled and the packages might get picked up as if they were final or whatever.

How to avoid that?

Well, we make everything accessable by design.

But what I would suggest in your case would be that you work with two projects, one mozilla:STABLE and one mozilla:UNSTABLE.

You can prepare the release in unstable and submit or copy source from there to STABLE.

I'm not convinced about that since the build time in OBS sometimes is just too slow and when I move a final release I never know when it will be available for download. For security updates I don't want that. I'm caring about the fact that my security updates are available at the same time as upstream releases. I want to just switch a flag to publish packages otherwise I'm getting turnaround times in bad situations which are not acceptable (to me). In addition I by far enough mozilla repositories to care about (I still could use mozilla:beta but given the above I don't see that as an option). Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 12/02/2009 03:24 PM, Henne Vogelsang wrote:

Wolfgang Rosenauer wrote:

...

Now as the repo is popular there are people linking to packages from there but in their repos publishing is not disabled and the packages might get picked up as if they were final or whatever.

How to avoid that?

How do you avoid that people checkout the mozilla svn and build the package locally and then publish those on their geocities homepage. Simple: You don't :)

Right, but in OBS it's easy to find through software.opensuse.org for example. I don't find it critical but it's confusing users. Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 12/02/2009 03:54 PM, Petit Eric wrote:

Just an idea, but since the package is unstable, could you simply add Unstable, beta or svn in your release version number and then , when package are stable, remove that ?

I'm really looking for ideas but this one is the same as having another repo to do it. Changing the release number would again require a complete build for all affected distributions and if needed in the wrong moment it takes half of a week to be available after the change. So with current OBS I still think that the only way is how I do it currently with the effect that testing packages make it through to foreign projects. Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Mittwoch, 2. Dezember 2009 16:13:33 schrieb Cristian Morales Vega:

2009/12/2 Wolfgang Rosenauer :

...

Hi,

I've raised that issue long time ago already but there was no real outcome IIRC.

As I'm managing a a popular repository which should be kept as stable and reliable as possible I turning publishing off when I prepare a new update package. I do that even before upstream released the update officially to be able to release it at about the same time. Now as the repo is popular there are people linking to packages from there but in their repos publishing is not disabled and the packages might get picked up as if they were final or whatever.

How to avoid that?

We have https://bugzilla.novell.com/440894 IMHO Dirk suggestion of automatically disabling publishing recursively makes a lot of sense. If you are linking against another project it is because you are compiling against libraries in there. If those libraries aren't available to users the binaries compiled against them should also be unavailable to users.

Yes, but it is not so easy. For example all Base projects atm have publishing disabled, also factory. (Because they get published via the products)... But I will think about that again once I have finally added the repository state handling ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wednesday 02 December 2009 16:43:29 Petit Eric wrote:

Another idea/feature, could be a flag (expert) to lock/prevent other user to link our project/pkg ?

While I also don't like the idea it wouldn't work anyways since people would just copy the source then which kinda defeats the _link purpose. IMHO it just isn't worth the worries. If people decide to use some random home repo instead of a clearly named "Mozilla" top level one they earn all the hassle they get. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

2009/12/2 Ludwig Nussel :

Cristian Morales Vega wrote:

...

2009/12/2 Wolfgang Rosenauer :

...

I've raised that issue long time ago already but there was no real outcome IIRC.

As I'm managing a a popular repository which should be kept as stable and reliable as possible I turning publishing off when I prepare a new update package. I do that even before upstream released the update officially to be able to release it at about the same time. Now as the repo is popular there are people linking to packages from there but in their repos publishing is not disabled and the packages might get picked up as if they were final or whatever.

How to avoid that?

We have https://bugzilla.novell.com/440894 IMHO Dirk suggestion of automatically disabling publishing recursively makes a lot of sense. If you are linking against another project it is because you are compiling against libraries in there. If those libraries aren't available to users the binaries compiled against them should also be unavailable to users.

Not a good idea IMO. The packages in the disabled repo could be used for building only (e.g. backport of newer cmake or some static library).

True. So do it only with repositories without the flag from https://bugzilla.novell.com/505471 The flag is needed anyway for the 1-Click case. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org