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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-20-2011, 05:42 PM
Diego Elio Pettenò
 
Default On hosting self-produced distfiles

Il giorno gio, 20/01/2011 alle 13.34 -0500, Anthony G. Basile ha
scritto:
>
> shows 39 eclasses which refer to mirror://

That's not much of a problem, mirror://kde/ mirror://debian/ and the
like are fine, most of the time.

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
 
Old 01-20-2011, 05:51 PM
Diego Elio Pettenò
 
Default On hosting self-produced distfiles

Il giorno gio, 20/01/2011 alle 19.41 +0100, Matti Bickel ha scritto:
>
> So, I'm not opposed to your idea. If ya want to archive your stuff
> forever, by all means do it. I just see no point in forcing this on
> all
> devs. So, care to explain or give me pointer on why this is necessary?
>

License compliance when distributing binaries; distributions built upon
Gentoo that might use old and set-in-stone Portage trees; security
issues that might be reported and needs to be investigated, ...

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
 
Old 01-20-2011, 06:27 PM
Matti Bickel
 
Default On hosting self-produced distfiles

First, thanks for pointing this out.

On 01/20/2011 07:51 PM, Diego Elio Petten wrote:
> License compliance when distributing binaries;

Not sure what you mean: if someone quickpkg's php and needs all the
source? Well, they already downloaded them. Better keep them around,
since it's *your* binary, not mine.

> distributions built upon Gentoo that might use old and set-in-stone
> Portage trees;

Same thing, as already pointed out in another message. I see the point
in making it easier for them. That's okay. So what you're saying is
we're upstream too and upstream's should provide their historical stuff.

> security issues that might be reported and needs to be
> investigated, ...

If you're reporting a security issue in a ebuild that's no longer in
tree (in php's case, chances are it got removed b/c of security ), the
bug wouldn't be investigated, right?
 
Old 01-20-2011, 06:28 PM
Mike Frysinger
 
Default On hosting self-produced distfiles

On Wednesday, January 19, 2011 22:57:59 Diego Elio Petten wrote:
> Il giorno mer, 19/01/2011 alle 22.31 -0500, Mike Frysinger ha scritto:
> > we havent
> >
> > hosted files on dev.g.o because we've felt the distfiles tree to be
> > sufficient. since there seems to be more need now, let's find out
> > what infra
> > can do to help out.
>
> I'm pretty sure you have, for pax-utils and portage-utils, didn't you?

my personal choice to keep an archive of packages i build does not mean a hard
policy must be forced upon everyone.

> > here's a better idea: figure out something with the infra team.
> > [snip]
> > again, declaring policy ahead of talking to anyone else is not the way
> > to go.
>
> Actually, we meant to move to a stable archive of distfiles for years,
> and Robin has been working on it for months already.

then you should have mentioned this in your original e-mail rather than
painting infra as angry unhelpful tools. the changes you propose are merely a
stop gap measure until infra finishes their work.
-mike
 
Old 01-20-2011, 06:30 PM
Mike Frysinger
 
Default On hosting self-produced distfiles

On Thursday, January 20, 2011 13:51:23 Diego Elio Petten wrote:
> Il giorno gio, 20/01/2011 alle 19.41 +0100, Matti Bickel ha scritto:
> > So, I'm not opposed to your idea. If ya want to archive your stuff
> > forever, by all means do it. I just see no point in forcing this on
> > all
> > devs. So, care to explain or give me pointer on why this is necessary?
>
> License compliance when distributing binaries

how is this relevant ? if there are issues with distributing binaries, then
were they get distributed isnt important.

> distributions built upon Gentoo that might use old and set-in-stone Portage
> trees

last i heard, the FSF's interpretation of the GPL was that this is the problem
of said derivatives. i'm not saying we shouldnt help out where possible, just
that we shouldnt be bending over backwards for them. they want to stay
behind, then that is their problem.
-mike
 
Old 01-20-2011, 06:42 PM
Diego Elio Pettenò
 
Default On hosting self-produced distfiles

Il giorno gio, 20/01/2011 alle 20.27 +0100, Matti Bickel ha scritto:
> Not sure what you mean: if someone quickpkg's php and needs all the
> source? Well, they already downloaded them. Better keep them around,
> since it's *your* binary, not mine.

We do distribute part of our packages as binaries already so we have to
be compliant with their licenses to begin with. Better doing it with a
single sweep than trying to come up with abstruse case-by-case points,
no?

> Same thing, as already pointed out in another message. I see the point
> in making it easier for them. That's okay. So what you're saying is
> we're upstream too and upstream's should provide their historical stuff.

This is but _one_ reason, and just another thing to trickle down. I
don't care if "FSF says it's their problem"; what is it costing us,
really? The cost is minimal (as we need the archive anyway), and the
gain is there for many people.

Arguing against this is just getting to the point of arguing because
somebody is doing what nobody did for a long time: taking decisions.

> If you're reporting a security issue in a ebuild that's no longer in
> tree (in php's case, chances are it got removed b/c of security ), the
> bug wouldn't be investigated, right?

There are cases and cases there; in the case of _custom_ tarballs, I'd
expect us to investigate if the security issues was found on our version
and not in the upstream-provided one for instance.

Once again, please tell me: what does it change to you? If anybody
should complain about this request is Infra. And Infra in the person of
Robin is okay with this policy as it was planned anyway.

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
 
Old 01-20-2011, 06:47 PM
Diego Elio Pettenò
 
Default On hosting self-produced distfiles

Il giorno gio, 20/01/2011 alle 14.28 -0500, Mike Frysinger ha scritto:
>
> then you should have mentioned this in your original e-mail rather
> than
> painting infra as angry unhelpful tools. the changes you propose are
> merely a
> stop gap measure until infra finishes their work.

You of all people to sound surprised about this really doesn't look
right. The fact that such an archive has been in the work is something
know since I became a dev, six years ago; the bug was open in 2007.

Also "angry unhelpful tools"? You're putting words in my mail that
aren't there. I said infra _used_ to be against that; it was obvious
that knowing that I wouldn't just push the issue against their will.

If you were trying to pick a fight for the sake of it, I'd suggest you
find something else to do.

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
 
Old 01-20-2011, 07:02 PM
Jeroen Roovers
 
Default On hosting self-produced distfiles

On Thu, 20 Jan 2011 14:25:23 +0100
Diego Elio Pettenò <flameeyes@gmail.com> wrote:

> Il giorno gio, 20/01/2011 alle 07.23 +0100, "Paweł Hajdan, Jr." ha
> scritto:
> >
> > Storing distfiles in public_html is not a perfect solution either.
> > If the developer retires, what do we do with the files?
>
> That's why (and I answer to Peter here as well), it is an ad interim
> solution. As I said and repeated Robin is working on the final one but
> until then we still prefer this method.

It isn't exactly a solution and the interim has lasted for years now.

What legitimate use does mirror://gentoo retain when we do have a
solution? Ultimate patch attached.

The way I see it, losing important files because you didn't
store copies privately or publicly is not a problem our distfiles
mirrors should solve.

Having SRC_URI files taking up space indefinitely because of a special
SRC_URI value is not the solution either, say when we would create a
static-distfiles.gentoo.org for that purpose.

What if an upstream dies? Lots of packages have broken SRC_URIs because
of that, and yet as long as the ebuilds are in the tree, the files are
nicely mirrored for us.

So, as asked here and there in this thread, what exact problem are we
solving? Hopefully not merely the loss of some files in the past?


jer
 
Old 01-20-2011, 07:23 PM
Diego Elio Pettenò
 
Default On hosting self-produced distfiles

Il giorno gio, 20/01/2011 alle 21.02 +0100, Jeroen Roovers ha scritto:
> It isn't exactly a solution and the interim has lasted for years now.

No, for years now we had policies going one way ("don't use dev.g.o")
because they were written at one point by one person, and practices for
most of us going the other (using dev.gentoo.org), as the original
reason not to use it is no longer relevant.

Now we're re-joining policy and practice.

> What legitimate use does mirror://gentoo retain when we do have a
> solution? Ultimate patch attached.

Yes and? We're going to have a distinct mirror://gentoo-projects/ (just
to be on the safe side for overlays mainly) to fetch the distfiles for
the custom packages.

> The way I see it, losing important files because you didn't
> store copies privately or publicly is not a problem our distfiles
> mirrors should solve.

For Gentoo-produced distfiles, it is nothing new that we have to have
long term access available. We've been meaning to for years as you said.
I'm positive that the issue went to the council once already.

Let's be clear here: Infra is the same page as this; this _is_ going
through. This was being worked on for months and months, and people
start complain now because... they are being asked for all of us to
follow a single policy rather than case-by-case whether to delete
distfiles or not?

There isn't _more_ work to be done with the exception of using a script
that signs the files rather than simply scp'ing them over, so it's not a
matter of "you're asking us to do more work in the future" as much as
"you're asking us to follow a procedure". Well, duh!

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
 
Old 01-20-2011, 07:35 PM
Matti Bickel
 
Default On hosting self-produced distfiles

On 01/20/2011 08:42 PM, Diego Elio Petten wrote:
> We do distribute part of our packages as binaries already so we have to
> be compliant with their licenses to begin with. Better doing it with a
> single sweep than trying to come up with abstruse case-by-case points,
> no?

No. Licenses are not a valid argument to me. I'd accept that if we're
Debian and pushing 100% of *our* stuff as binary. What we do 90% of the
time is distributing text - ebuilds.

> Arguing against this is just getting to the point of arguing because
> somebody is doing what nobody did for a long time: taking decisions.

Yes, and I'm not going to stop you. Frankly, I don't care enough where
my tarballs end up. I just was curious about the reasons, as I see no
compelling point in *forcing* this.

>> If you're reporting a security issue in a ebuild that's no longer in
>> tree (in php's case, chances are it got removed b/c of security ), the
>> bug wouldn't be investigated, right?
>
> There are cases and cases there; in the case of _custom_ tarballs, I'd
> expect us to investigate if the security issues was found on our version
> and not in the upstream-provided one for instance.

Take php-5.3.2: I don't care if you found a security issue in my tarball
or in php's tarball. I'll have a look to determine if the bug's still in
the newest version. If it is, I'll rename the bug. If it is not, it
doesn't matter to me.

> Once again, please tell me: what does it change to you? If anybody
> should complain about this request is Infra.

What it changes for me? The target argument of my scp command. Which is
so small that I don't care (see above for why I still replied).
 

Thread Tools




All times are GMT. The time now is 01:14 PM.

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