RFC: forbid _service files

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: forbid _service files

Stephan Kulow-2
Hi,

After a series of broken packages because of _service files I would like to
forbid them in openSUSE:Factory.

So far I've seen the use of _service files in factory as an experiment (I
happily joined), but I see this experiment as failed.

What I would like to propose is:
 - ban recompress, download and tarscm as _services (everything else should
   have been banned before)
 - instead we verify the Source urls and make packages that have invalid URLs
   "broken", so you can't SR them to factory.

This means: the Source URL is now an important thing to change and no longer a
bit rotting comment and we stop recompressing tars - this was a proposal from
Adrian a while ago without much objection.

Please comment or I will go forward.

Greetings, Stephan
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Cristian Morales Vega
2011/5/3 Stephan Kulow <[hidden email]>:
> After a series of broken packages because of _service files I would like to
> forbid them in openSUSE:Factory.
>
> So far I've seen the use of _service files in factory as an experiment (I
> happily joined), but I see this experiment as failed.

As a happy _service files user I would object... unless I would know
more about "a series of broken packages".
Sure, I had a problem recently. But it was a lot worse before, things
have been improving a lot for me.

So, why you see it as failed?

>  - instead we verify the Source urls and make packages that have invalid URLs
>   "broken", so you can't SR them to factory.

What do you mean with "verify"? If you mean verify the URL is not
malformed, I don't think that would be really useful. If you mean use
wget/curl on it, and check the submitted and downloaded tarballs
match... well, that's what _service files do now.
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stephan Kulow-2
Am Dienstag, 3. Mai 2011 schrieb Cristian Morales Vega:
> 2011/5/3 Stephan Kulow <[hidden email]>:
> > After a series of broken packages because of _service files I would like
> > to forbid them in openSUSE:Factory.
> >
> > So far I've seen the use of _service files in factory as an experiment (I
> > happily joined), but I see this experiment as failed.
>
> As a happy _service files user I would object... unless I would know
> more about "a series of broken packages".
See Vincent's mail this morning - this was not even the last one.

> Sure, I had a problem recently. But it was a lot worse before, things
> have been improving a lot for me.
What packages in factory do you have with _service files and what do they use?

>
> So, why you see it as failed?
>
> >  - instead we verify the Source urls and make packages that have invalid
> > URLs "broken", so you can't SR them to factory.
>
> What do you mean with "verify"? If you mean verify the URL is not
> malformed, I don't think that would be really useful. If you mean use
> wget/curl on it, and check the submitted and downloaded tarballs
> match... well, that's what _service files do now.
I mean to wget/curl them and check that it's the same as in the package and
not something unrelated, but the source tar would stay in the package and
wouldn't be regenerated/recommited on every source change. People clearly
expect a osc commit after a working local build to also work on the server.

Greetings, Stephan

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

gregkh
In reply to this post by Stephan Kulow-2
On Tue, May 03, 2011 at 04:12:32PM +0200, Stephan Kulow wrote:

> Hi,
>
> After a series of broken packages because of _service files I would like to
> forbid them in openSUSE:Factory.
>
> So far I've seen the use of _service files in factory as an experiment (I
> happily joined), but I see this experiment as failed.
>
> What I would like to propose is:
>  - ban recompress, download and tarscm as _services (everything else should
>    have been banned before)
>  - instead we verify the Source urls and make packages that have invalid URLs
>    "broken", so you can't SR them to factory.
>
> This means: the Source URL is now an important thing to change and no longer a
> bit rotting comment and we stop recompressing tars - this was a proposal from
> Adrian a while ago without much objection.
>
> Please comment or I will go forward.

Makes sense to me, please go forward with this.

greg k-h
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Guido Berhoerster-6
In reply to this post by Stephan Kulow-2
* Stephan Kulow <[hidden email]> [2011-05-03 16:12]:
> This means: the Source URL is now an important thing to change and no longer a
> bit rotting comment and we stop recompressing tars - this was a proposal from
> Adrian a while ago without much objection.
>
> Please comment or I will go forward.

For all source files? How does that deal with snapshots from scm
and custom local source files? What is the actual benefit (apart
from knowing there is a file of the same name somewhere on the
net)?

--
Guido Berhoerster
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stephan Kulow-2
Am Dienstag, 3. Mai 2011 schrieb Guido Berhoerster:
> * Stephan Kulow <[hidden email]> [2011-05-03 16:12]:
> > This means: the Source URL is now an important thing to change and no
> > longer a bit rotting comment and we stop recompressing tars - this was a
> > proposal from Adrian a while ago without much objection.
> >
> > Please comment or I will go forward.
>
> For all source files? How does that deal with snapshots from scm
> and custom local source files? What is the actual benefit (apart
If there is no URL as Source, it's of course not possible to validate.

> from knowing there is a file of the same name somewhere on the
> net)?
We would validate more than the name - and that would make sure you can't
pretend you upload linus kernel but instead upload something fishy.

Greetings, Stephan

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Jiri Slaby-6
In reply to this post by Stephan Kulow-2
On 05/03/2011 04:12 PM, Stephan Kulow wrote:

> Hi,
>
> After a series of broken packages because of _service files I would like to
> forbid them in openSUSE:Factory.
>
> So far I've seen the use of _service files in factory as an experiment (I
> happily joined), but I see this experiment as failed.
>
> What I would like to propose is:
>  - ban recompress, download and tarscm as _services (everything else should
>    have been banned before)
>  - instead we verify the Source urls and make packages that have invalid URLs
>    "broken", so you can't SR them to factory.
>
> This means: the Source URL is now an important thing to change and no longer a
> bit rotting comment and we stop recompressing tars - this was a proposal from
> Adrian a while ago without much objection.
>
> Please comment or I will go forward.

I don't have a problem with that. But only if there is a way to convert
from _service to non-_service at the Factory gate. Or is it what will be
done when "ban" is forced?

The packages are much easier to update when _service file is used.

thanks,
--
js
suse labs
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Cristian Morales Vega
In reply to this post by Stephan Kulow-2
2011/5/3 Stephan Kulow <[hidden email]>:

> Am Dienstag, 3. Mai 2011 schrieb Cristian Morales Vega:
>> 2011/5/3 Stephan Kulow <[hidden email]>:
>> > After a series of broken packages because of _service files I would like
>> > to forbid them in openSUSE:Factory.
>> >
>> > So far I've seen the use of _service files in factory as an experiment (I
>> > happily joined), but I see this experiment as failed.
>>
>> As a happy _service files user I would object... unless I would know
>> more about "a series of broken packages".
> See Vincent's mail this morning - this was not even the last one.

It looks like a minor problem, either it's a big download or you must
be really fast to create a SR before the service has completed. And it
should be simple enough to solve. In fact it's already solved in the
client side.
I don't look every day at Factory build errors, you know better than
me the number and severity of the problems. But from my corner it
seems right now _service files create nearly zero problems, I could be
wrong...

>> Sure, I had a problem recently. But it was a lot worse before, things
>> have been improving a lot for me.
> What packages in factory do you have with _service files and what do they use?

Which I consider mine: libgme, libebml, libmatroska and mkvtoolnix.
All of them use download_url, verify_file and set_version. I don't
remember having a problem with them ever.
They are not the packages that could benefit the most from services,
but it still makes life easier when someone submit requests me an
upstream update to the devel project.

>> >  - instead we verify the Source urls and make packages that have invalid
>> > URLs "broken", so you can't SR them to factory.
>>
>> What do you mean with "verify"? If you mean verify the URL is not
>> malformed, I don't think that would be really useful. If you mean use
>> wget/curl on it, and check the submitted and downloaded tarballs
>> match... well, that's what _service files do now.
> I mean to wget/curl them and check that it's the same as in the package and
> not something unrelated, but the source tar would stay in the package and
> wouldn't be regenerated/recommited on every source change. People clearly
> expect a osc commit after a working local build to also work on the server.

And this isn't exactly what download_url and verify_file are doing
now? You want to change the current services for a different
implementation that does exactly the same?? I will expect a new
implementation to be buggier.
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Brian K. White
In reply to this post by Stephan Kulow-2
On 5/3/2011 10:12 AM, Stephan Kulow wrote:

> Hi,
>
> After a series of broken packages because of _service files I would like to
> forbid them in openSUSE:Factory.
>
> So far I've seen the use of _service files in factory as an experiment (I
> happily joined), but I see this experiment as failed.
>
> What I would like to propose is:
>   - ban recompress, download and tarscm as _services (everything else should
>     have been banned before)
>   - instead we verify the Source urls and make packages that have invalid URLs
>     "broken", so you can't SR them to factory.
>
> This means: the Source URL is now an important thing to change and no longer a
> bit rotting comment and we stop recompressing tars - this was a proposal from
> Adrian a while ago without much objection.
>
> Please comment or I will go forward.
>
> Greetings, Stephan

Does everything actually have a valid url that goes to an archive?
Some things just have web sites where the download link is a cgi,
sometimes a poorly written cgi, and no direct simple link to the actual
archive is offered, and trying to wget/curl the url doesn't work or
doesn't work as desired.

I actually have a couple of small packages of my own that I do not host
anywhere else but in the build service. The build service essentially
_is_ the most upstream root source for this code.

Then there are git/hg/svn snapshots

Then there are packages whose real original host/maintainer have long
since gone away and all there are now are many places that maintain it,
but none can be considered the new authoritative upstream maintainer.

--
bkw
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Adrian Schröter
In reply to this post by Cristian Morales Vega
Am Dienstag, 3. Mai 2011, 19:24:35 schrieb Cristian Morales Vega:

> 2011/5/3 Stephan Kulow <[hidden email]>:
> > Am Dienstag, 3. Mai 2011 schrieb Cristian Morales Vega:
> >> 2011/5/3 Stephan Kulow <[hidden email]>:
> >> > After a series of broken packages because of _service files I would like
> >> > to forbid them in openSUSE:Factory.
> >> >
> >> > So far I've seen the use of _service files in factory as an experiment (I
> >> > happily joined), but I see this experiment as failed.
> >>
> >> As a happy _service files user I would object... unless I would know
> >> more about "a series of broken packages".
> > See Vincent's mail this morning - this was not even the last one.
>
> It looks like a minor problem, either it's a big download or you must
> be really fast to create a SR before the service has completed. And it
> should be simple enough to solve. In fact it's already solved in the
> client side.
> I don't look every day at Factory build errors, you know better than
> me the number and severity of the problems. But from my corner it
> seems right now _service files create nearly zero problems, I could be
> wrong...

I still want to solve open problems at least ;)

However, the new way coolo suggested can be implemented via project wide
source service. The download_url service can be replaced by a project wide download_files
service. It would download the files according to spec file URL.

combining this with new osc and "trylocal" option it would offer both ways,
submitting the downloaded tar ball together with the submission and let
the server just validated. Or trigger it to server side download when bandwidth
problems exist for packagers with packages with large tar balls.

However, I still see the need to allow to run tar_scm. At least manually created
tar balls would be a step backward IMHO.
 

> >> Sure, I had a problem recently. But it was a lot worse before, things
> >> have been improving a lot for me.
> > What packages in factory do you have with _service files and what do they use?
>
> Which I consider mine: libgme, libebml, libmatroska and mkvtoolnix.
> All of them use download_url, verify_file and set_version. I don't
> remember having a problem with them ever.
> They are not the packages that could benefit the most from services,
> but it still makes life easier when someone submit requests me an
> upstream update to the devel project.
>
> >> >  - instead we verify the Source urls and make packages that have invalid
> >> > URLs "broken", so you can't SR them to factory.
> >>
> >> What do you mean with "verify"? If you mean verify the URL is not
> >> malformed, I don't think that would be really useful. If you mean use
> >> wget/curl on it, and check the submitted and downloaded tarballs
> >> match... well, that's what _service files do now.
> > I mean to wget/curl them and check that it's the same as in the package and
> > not something unrelated, but the source tar would stay in the package and
> > wouldn't be regenerated/recommited on every source change. People clearly
> > expect a osc commit after a working local build to also work on the server.
>
> And this isn't exactly what download_url and verify_file are doing
> now? You want to change the current services for a different
> implementation that does exactly the same?? I will expect a new
> implementation to be buggier.

it would be also a source service implementation but using the project wide
services. I planned to write something more informative about this, so far there
is only our book chapter:

  http://doc.opensuse.org/products/draft/OBS/obs-reference-guide_draft/cha.obs.source_service.html#id375663

--
Adrian Schroeter
SUSE Linux Products GmbH
email: [hidden email]

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stephan Kulow-2
In reply to this post by Jiri Slaby-6
Am Dienstag, 3. Mai 2011 schrieb Jiri Slaby:
>
> I don't have a problem with that. But only if there is a way to convert
> from _service to non-_service at the Factory gate. Or is it what will be
> done when "ban" is forced?
>
> The packages are much easier to update when _service file is used.
Why is it easier? Perhaps I'm seeing the use case differently.

Greetings, Stephan
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Jiri Slaby-6
On 05/04/2011 09:31 AM, Stephan Kulow wrote:
> Am Dienstag, 3. Mai 2011 schrieb Jiri Slaby:
>>
>> I don't have a problem with that. But only if there is a way to convert
>> from _service to non-_service at the Factory gate. Or is it what will be
>> done when "ban" is forced?
>>
>> The packages are much easier to update when _service file is used.
> Why is it easier? Perhaps I'm seeing the use case differently.

Because one needs to change a single line to update a package from one
version to another. Maybe BS can handle URLs from SOURCE line (I'm not
sure about this) which would offer the same functionality. However it
for example doesn't recompress the tar from big gz's to much smaller
bz2's. And there are still people with low bandwidth like me where "osc
co" size matters (e.g. llvm is packaged only by gzip -- llvm-gcc .gz ~
52M, .bz2 ~ 39M).

tar_scm is another time-saver. There are perpetual-beta projects with no
releases at all (psi+ comes on my mind). The development occurs in a
repository and one doesn't need to do snapshots manually or find time
stamps of the last prepared snapshot. One "osc service remoterun" does
that all.

Really, isn't the obs/osc fixable to handle the _service files properly?
I cannot tell, since I don't know what exact problems there are in
Factory. I'm not fighting them every day. You do.

thanks,
--
js
suse labs
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Ludwig Nussel
In reply to this post by Stephan Kulow-2
Stephan Kulow wrote:
> After a series of broken packages because of _service files I would like to
> forbid them in openSUSE:Factory.
>
> So far I've seen the use of _service files in factory as an experiment (I
> happily joined), but I see this experiment as failed.

+1 for considering the current approach failed. +1 for not
recompressing sources.

However, I still think storing tarballs in some kind of source
caching service rather than alongside the spec file would be
beneficial. Not only for verification purpose but also to aid people
with a slow connection.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stephan Kulow-2
In reply to this post by Cristian Morales Vega
Am Dienstag, 3. Mai 2011 schrieb Cristian Morales Vega:
>
> And this isn't exactly what download_url and verify_file are doing
> now? You want to change the current services for a different
> implementation that does exactly the same?? I will expect a new
> implementation to be buggier.

The services are very similiar indeed, the only difference is that one
actually downloads and commits to duplicate the information in the Url
in a _service file and the other service only downloads and verifies without
commit.

Greetings, Stephan
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stephan Kulow-2
In reply to this post by Brian K. White
Am Dienstag, 3. Mai 2011 schrieb Brian K. White:
> Does everything actually have a valid url that goes to an archive?
> Some things just have web sites where the download link is a cgi,
> sometimes a poorly written cgi, and no direct simple link to the actual
> archive is offered, and trying to wget/curl the url doesn't work or
> doesn't work as desired.
Those don't use _service files atm either. So there is no change.

Greetings, Stephan

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stephan Kulow-2
In reply to this post by Jiri Slaby-6
Am Mittwoch, 4. Mai 2011 schrieb Jiri Slaby:

> On 05/04/2011 09:31 AM, Stephan Kulow wrote:
> > Am Dienstag, 3. Mai 2011 schrieb Jiri Slaby:
> >> I don't have a problem with that. But only if there is a way to convert
> >> from _service to non-_service at the Factory gate. Or is it what will be
> >> done when "ban" is forced?
> >>
> >> The packages are much easier to update when _service file is used.
> >
> > Why is it easier? Perhaps I'm seeing the use case differently.
>
> Because one needs to change a single line to update a package from one
> version to another. Maybe BS can handle URLs from SOURCE line (I'm not
> sure about this) which would offer the same functionality. However it
> for example doesn't recompress the tar from big gz's to much smaller
> bz2's. And there are still people with low bandwidth like me where "osc
> co" size matters (e.g. llvm is packaged only by gzip -- llvm-gcc .gz ~
> 52M, .bz2 ~ 39M).
With _service files you download the original tar ball too. Very often even
more often than once.
>
> tar_scm is another time-saver. There are perpetual-beta projects with no
> releases at all (psi+ comes on my mind). The development occurs in a
> repository and one doesn't need to do snapshots manually or find time
> stamps of the last prepared snapshot. One "osc service remoterun" does
> that all.
So what you're saying is that you want to update huge sources in the OBS
without having them locally. All I want is basically that those sources are
then commited as fixed revision into the sourcetree without the service
running at every source change, but only if you use e.g. remoterun.

Perhaps we should not forbid _service files in general, but stop regenerating.

>
> Really, isn't the obs/osc fixable to handle the _service files properly?
> I cannot tell, since I don't know what exact problems there are in
> Factory. I'm not fighting them every day. You do.
Well, I don't "fight" them either - but I reject many packages and people
don't understand why. And the reason they don't understand it is that
source services  behave in unexepcted ways.

Greetings, Stephan
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Brian K. White
In reply to this post by Stephan Kulow-2
On 5/4/2011 4:13 AM, Stephan Kulow wrote:

> Am Dienstag, 3. Mai 2011 schrieb Brian K. White:
>> Does everything actually have a valid url that goes to an archive?
>> Some things just have web sites where the download link is a cgi,
>> sometimes a poorly written cgi, and no direct simple link to the actual
>> archive is offered, and trying to wget/curl the url doesn't work or
>> doesn't work as desired.
> Those don't use _service files atm either. So there is no change.
>
> Greetings, Stephan
>

The point was that you suggested making the source url comment important
instead of just a comment.

I put whatever I can in the source url comment (in spec files) that will
point the way to how to get the upstream source, and there is always
_something_ I can put there, but it is not always something that can be
automated, or that should be considered any more authoritative than the
locally hosted copy, for instance, the debian or redhat version of a
package that no longer has any official upstream source, or a known
broken link that was the last known location and that's better than
forgetting the info, or a wayback machine link, etc.

Those and other possible things that might appear in the source url
comment are not usable for automated download or verify, and sometimes
there is no better thing to put there. So making that comment important
is not sensible to me, at least not without making it
voluntary/optional, where it's only invoked by putting a special string
in there, or less-good, disabled by putting a special string in there.

If that is not what you meant, or you meant to allow for this somehow,
then never mind.

--
bkw
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stephan Kulow-2
Am Mittwoch, 4. Mai 2011 schrieb Brian K. White:

> On 5/4/2011 4:13 AM, Stephan Kulow wrote:
> > Am Dienstag, 3. Mai 2011 schrieb Brian K. White:
> >> Does everything actually have a valid url that goes to an archive?
> >> Some things just have web sites where the download link is a cgi,
> >> sometimes a poorly written cgi, and no direct simple link to the actual
> >> archive is offered, and trying to wget/curl the url doesn't work or
> >> doesn't work as desired.
> >
> > Those don't use _service files atm either. So there is no change.
> >
> > Greetings, Stephan
>
> The point was that you suggested making the source url comment important
> instead of just a comment.
>
> I put whatever I can in the source url comment (in spec files) that will
> point the way to how to get the upstream source, and there is always
> _something_ I can put there, but it is not always something that can be
> automated, or that should be considered any more authoritative than the
> locally hosted copy, for instance, the debian or redhat version of a
> package that no longer has any official upstream source, or a known
> broken link that was the last known location and that's better than
> forgetting the info, or a wayback machine link, etc.

>
> Those and other possible things that might appear in the source url
> comment are not usable for automated download or verify, and sometimes
> there is no better thing to put there. So making that comment important
> is not sensible to me, at least not without making it
> voluntary/optional, where it's only invoked by putting a special string
> in there, or less-good, disabled by putting a special string in there.
It has to be correct at the moment when you submit it. If it can't be correct
for reasons given by you, then don't put them in the Source: url but in a
comment. If it turns broken at some later point, it's of course out of your
control, but that doesn't mean you should write bogus URIs in spec files
just because you can.

Greetings, Stephan
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Richard Biener
In reply to this post by Stephan Kulow-2
On Wed, 4 May 2011, Stephan Kulow wrote:

> Am Mittwoch, 4. Mai 2011 schrieb Jiri Slaby:
> > On 05/04/2011 09:31 AM, Stephan Kulow wrote:
> > > Am Dienstag, 3. Mai 2011 schrieb Jiri Slaby:
> > >> I don't have a problem with that. But only if there is a way to convert
> > >> from _service to non-_service at the Factory gate. Or is it what will be
> > >> done when "ban" is forced?
> > >>
> > >> The packages are much easier to update when _service file is used.
> > >
> > > Why is it easier? Perhaps I'm seeing the use case differently.
> >
> > Because one needs to change a single line to update a package from one
> > version to another. Maybe BS can handle URLs from SOURCE line (I'm not
> > sure about this) which would offer the same functionality. However it
> > for example doesn't recompress the tar from big gz's to much smaller
> > bz2's. And there are still people with low bandwidth like me where "osc
> > co" size matters (e.g. llvm is packaged only by gzip -- llvm-gcc .gz ~
> > 52M, .bz2 ~ 39M).
> With _service files you download the original tar ball too. Very often even
> more often than once.
> >
> > tar_scm is another time-saver. There are perpetual-beta projects with no
> > releases at all (psi+ comes on my mind). The development occurs in a
> > repository and one doesn't need to do snapshots manually or find time
> > stamps of the last prepared snapshot. One "osc service remoterun" does
> > that all.
> So what you're saying is that you want to update huge sources in the OBS
> without having them locally. All I want is basically that those sources are
> then commited as fixed revision into the sourcetree without the service
> running at every source change, but only if you use e.g. remoterun.
>
> Perhaps we should not forbid _service files in general, but stop regenerating.
I'm not sure what the actual problem is but the time the service is
processed bothered me as well.  In some discussion with Adrian I suggested
that it has to occur exactly once, atomically with the osc commit
(so that when it fails the commit fails).  I'm not sure where we are
currently re-generating stuff.

Richard.

--
Richard Guenther <[hidden email]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Reply | Threaded
Open this post in threaded view
|

Re: RFC: forbid _service files

Stefan Seyfried
In reply to this post by Stephan Kulow-2
On Wed, 4 May 2011 10:20:22 +0200
Stephan Kulow <[hidden email]> wrote:

> With _service files you download the original tar ball too. Very often even
> more often than once.

for many people, download bandwidth is a less scarce resource than upload
bandwidth

> So what you're saying is that you want to update huge sources in the OBS
> without having them locally.

No, without having to first download them and then upload them into OBS
when OBS can just download them from the original source.

--
Stefan Seyfried

"Dispatch war rocket Ajax to bring back his body!"
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12