FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Advisory Board

 
 
LinkBack Thread Tools
 
Old 11-21-2007, 01:48 PM
Matt Domsch
 
Default Fedora Board Recap 2007-NOV-13

On Wed, Nov 21, 2007 at 09:38:43AM -0500, Jesse Keating wrote:
> On Wed, 21 Nov 2007 09:30:39 -0500
> seth vidal <skvidal@fedoraproject.org> wrote:
>
> > But if we have the source tarball and spec file + patches in cvs -
> > which we do right now, anyway, why not generate them on demand and
> > not even need to host the srpms until they're desired?
> >
> > We save space even in the short run.
>
> Because that will overtime potentially generate something that is
> different than the original srpm

And really, that's OK. We don't have to provide exactly the same
SRPM. We have to provide the sources that went into the binary. If
we provide that in a convenient SRPM form, that's fine - that's easy
for our existing tools to consume. But we could post directories full
of look-aside cache tarballs and patches if we wanted to.

-Matt

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 01:58 PM
Jeroen van Meeuwen
 
Default Fedora Board Recap 2007-NOV-13

seth vidal wrote:

On Wed, 2007-11-21 at 15:30 +0100, Jeroen van Meeuwen wrote:

seth vidal wrote:

3 years is a long time for keeping the sources around if we generate
them that way. It seems like we're better off in terms of space and in
terms of being able to provide sources for the longer run if we can
generate srpms on the fly out of cvs.

However once you choose to generate srpms on the fly out of cvs, you are
also committing to using cvs for the same amount of time. Migrating the
cvs component to anything else might show to have a huge tail and might
just not work in the sense that the new vcs might not give you srpms
with the same checksum, or <insert-favorite-unforeseen-hurdle-here>.




No we aren't committing to using cvs. We're committing to the tool
which generates the srpms being able to talk to whatever we're using in
the future.



I'm sorry I see now I shouldn't have used 'cvs' there but the point was
that we would need to be able to consistently generate the same file
over and over again. However while typing this message I read:


Matt Domsch wrote:
> And really, that's OK. We don't have to provide exactly the same
> SRPM. We have to provide the sources that went into the binary. If
> we provide that in a convenient SRPM form, that's fine - that's easy
> for our existing tools to consume. But we could post directories full
> of look-aside cache tarballs and patches if we wanted to.

So it seems the point is that it doesn't matter how or where from srpms
are being created (although it seems to me a spec file with some (in the
future, say 3 years from now- obsoleted tags will only be able to
generate a valid srpm by a fully backwards compatible RPM implementation
on the host, or we're gonna need to mock it all), and that we save space
if we do; provided this actually works now and does so for a long, long
period of time what's holding us back from trying to accomplish this
-regardless of FP actually distributing under 3b or not?


Kind regards,

Jeroen "archives everything anyway" van Meeuwen
-kanarip

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 02:04 PM
Jesse Keating
 
Default Fedora Board Recap 2007-NOV-13

On Wed, 21 Nov 2007 08:48:32 -0600
Matt Domsch <matt@domsch.com> wrote:

> And really, that's OK. We don't have to provide exactly the same
> SRPM. We have to provide the sources that went into the binary. If
> we provide that in a convenient SRPM form, that's fine - that's easy
> for our existing tools to consume. But we could post directories full
> of look-aside cache tarballs and patches if we wanted to.


Whatever we do, I want /extremely/ clear interpretation of which ever
GPL distribution method we choose to use. v2 3b/c are extremely vague
and I have severe issues with using them. v3 is not exactly better in
this regard. v2 3a is clear. v3 6a is pretty clear, and would apply
to handing out media at trade shows or via free media. v3 6d is pretty
clear and applies to how we do things today, except that it makes it
more clear that you can rely on some other party to host your source,
with the caveat that if the 3rd party goes away, you're still
responsible for making those sources available. v3 6e clarifies
bittorrent like distribution in that using v3 6d for source in
conjunction with v3 6e for binary is OK, provided that you make 6e
users aware of the location of 6d.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 02:15 PM
Jeroen van Meeuwen
 
Default Fedora Board Recap 2007-NOV-13

Jesse Keating wrote:

On Wed, 21 Nov 2007 08:48:32 -0600
Matt Domsch <matt@domsch.com> wrote:


And really, that's OK. We don't have to provide exactly the same
SRPM. We have to provide the sources that went into the binary. If
we provide that in a convenient SRPM form, that's fine - that's easy
for our existing tools to consume. But we could post directories full
of look-aside cache tarballs and patches if we wanted to.



Whatever we do, I want /extremely/ clear interpretation of which ever
GPL distribution method we choose to use. v2 3b/c are extremely vague
and I have severe issues with using them. v3 is not exactly better in
this regard. v2 3a is clear. v3 6a is pretty clear, and would apply
to handing out media at trade shows or via free media. v3 6d is pretty
clear and applies to how we do things today, except that it makes it
more clear that you can rely on some other party to host your source,
with the caveat that if the 3rd party goes away, you're still
responsible for making those sources available. v3 6e clarifies
bittorrent like distribution in that using v3 6d for source in
conjunction with v3 6e for binary is OK, provided that you make 6e
users aware of the location of 6d.



I wasn't aware that potentially distributing via GPLv3
<whatever-section> was in the picture too, but from what I understand v3
6d in combination with any form of the Fedora Project making the sources
available for a (limited) period of time would mean that:


1) it's very clear
2) downstream can point to sources hosted by the Fedora Project
3) sources do not have to be stored 3 years, but (for example) a one
release lifecycle


If possible, this certainly looks like a winner.

Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 02:34 PM
Jesse Keating
 
Default Fedora Board Recap 2007-NOV-13

On Wed, 21 Nov 2007 16:15:19 +0100
Jeroen van Meeuwen <kanarip@kanarip.com> wrote:

> 1) it's very clear
> 2) downstream can point to sources hosted by the Fedora Project
> 3) sources do not have to be stored 3 years, but (for example) a one
> release lifecycle
>
> If possible, this certainly looks like a winner.

Well, sources would need to be available for as long as downstreams
have done a binary release based from those sources. Whether Fedora
hosts those sources, or Fedora says they'll host those sources for a
period of time and then retire them, at which point the downstream has
to pick up the sources is debatable. Easier to manage if we provide
hosting for as many downstreams as possible, at least the exploaded
content so that hardlinks can be maximized.

I don't know if distribution via v3 is even possible at this point, I'm
just looking into the future.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 03:55 PM
Christopher Blizzard
 
Default Fedora Board Recap 2007-NOV-13

On Nov 21, 2007, at 9:02 AM, Jeroen van Meeuwen wrote:

Personally I am opposed to trying to find clever ways to not needing
to host the source (rpms). Finding ways to do anything different
from *just making the sources available online* for a period of time
is asking for trouble; It should work, but what if it doesn't -or
fails half-way? How does investing in a couple of discs weigh (each
release?) against the potential legal liability of losing anything
because in the past you thought you needed some 'clever way' to make
sources available.


There are a lot of things that we've wanted to do that this particular
requirement makes difficult. We're looking for ways to do it that
scale and still comply with the license. For example, if you have to
keep around a source rpm for anything that you might have possibly
ever might have distributed it makes for an explosion of disk space.
(Scratch builds? Personal builds?) However, sources and patches
don't explode anywhere near as quickly and if that can be carefully
archived in a way that makes the source easy to get, then we're doing
more than just complying with the license.


--Chris

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 03:56 PM
Christopher Blizzard
 
Default Fedora Board Recap 2007-NOV-13

On Nov 21, 2007, at 9:30 AM, Jeroen van Meeuwen wrote:

However once you choose to generate srpms on the fly out of cvs, you
are also committing to using cvs for the same amount of time.
Migrating the cvs component to anything else might show to have a
huge tail and might just not work in the sense that the new vcs
might not give you srpms with the same checksum, or <insert-favorite-
unforeseen-hurdle-here>.


Or you could just keep the old system around and not use it.

--Chris

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:00 PM
Jeroen van Meeuwen
 
Default Fedora Board Recap 2007-NOV-13

Jesse Keating wrote:

On Wed, 21 Nov 2007 16:15:19 +0100
Jeroen van Meeuwen <kanarip@kanarip.com> wrote:


1) it's very clear
2) downstream can point to sources hosted by the Fedora Project
3) sources do not have to be stored 3 years, but (for example) a one
release lifecycle


If possible, this certainly looks like a winner.


Well, sources would need to be available for as long as downstreams
have done a binary release based from those sources.


This isn't true. It's the other way around. Downstream may point to FP
as long as FP has these sources online. From the moment FP decides to
take these sources off-line it's up to downstream to decide whether they
take their binaries off-line or whether to continue hosting the sources
themselves. Practically FP would commit to, say, hosting the sources for
everything it releases for the life-cycle of the release -it's then up
to downstream whether they themselves extend that period by taking over.


Whether Fedora

hosts those sources, or Fedora says they'll host those sources for a
period of time and then retire them, at which point the downstream has
to pick up the sources is debatable. Easier to manage if we provide
hosting for as many downstreams as possible, at least the exploaded
content so that hardlinks can be maximized.



Am I correct to understand that you'd rather (offer to) host the sources
for downstream projects separately (but hard-linked as much as possible
to save some space), then just host (all of) the sources?


Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:02 PM
Jeroen van Meeuwen
 
Default Fedora Board Recap 2007-NOV-13

Christopher Blizzard wrote:


On Nov 21, 2007, at 9:30 AM, Jeroen van Meeuwen wrote:

However once you choose to generate srpms on the fly out of cvs, you
are also committing to using cvs for the same amount of time.
Migrating the cvs component to anything else might show to have a huge
tail and might just not work in the sense that the new vcs might not
give you srpms with the same checksum, or
<insert-favorite-unforeseen-hurdle-here>.


Or you could just keep the old system around and not use it.



Keeping old systems around doesn't sound very efficient -one goal that I
guess is attempted to be achieved by the "keeping-only-so-many-copies of
the sources re-generating the SRPM on demand" idea.


Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:07 PM
Jesse Keating
 
Default Fedora Board Recap 2007-NOV-13

On Wed, 21 Nov 2007 18:00:05 +0100
Jeroen van Meeuwen <kanarip@kanarip.com> wrote:

> This isn't true. It's the other way around. Downstream may point to
> FP as long as FP has these sources online. From the moment FP decides
> to take these sources off-line it's up to downstream to decide
> whether they take their binaries off-line or whether to continue
> hosting the sources themselves. Practically FP would commit to, say,
> hosting the sources for everything it releases for the life-cycle of
> the release -it's then up to downstream whether they themselves
> extend that period by taking over.

I think we just said the same thing but with different words.

>
> Whether Fedora
> > hosts those sources, or Fedora says they'll host those sources for a
> > period of time and then retire them, at which point the downstream
> > has to pick up the sources is debatable. Easier to manage if we
> > provide hosting for as many downstreams as possible, at least the
> > exploaded content so that hardlinks can be maximized.
> >
>
> Am I correct to understand that you'd rather (offer to) host the
> sources for downstream projects separately (but hard-linked as much
> as possible to save some space), then just host (all of) the sources?

Yes, because then we can prune more efficiently. As each binary
distribution is pruned, we can prune that specific reference to a
source package. If no more binary distributions exist with references
to the source package, then the actual file on the file system goes
away. There may be many interim updates that don't ever get included
in any binary distribution (other than our updates directory) and would
be pruned out automatically when the update is superseded.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 06:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org