Re: [gentoo-dev] Several portage trees

Re: [gentoo-dev] Several portage trees

[Joshua Brindle]

>> >As we know, Debian uses this. Everyone can add a new source of packages to get 
>> >installed to the system in a clear way. Just by putting deb lines into the 
>> >sources.list.
>> 
>> irrelavent
>ehh..... well, it's not irrelevant, IMHO. Debian has good things and bad
>things... 
>I think that Gentoo is reaching the top of his development model. We
>have seen this on thi delaying of recent packages. 
>
>Seemant is setting up the new development model. Maybe, what I'm saying
>it's an idea about it.

Wow, i haven't heard about this, you must be more informed than us developers

>> >So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several 
>> >trees allowed ).
>> >
>> >Is this too hard to implement?
>> >
>> >I think it solves a lot of complains about flexibility and edging of Gentoo.
>> 
>> this isn't a flexibility issue, it's trivial to download ebuilds and use them, 
>> write your own, distribute them, maintain your own portdir_overlay
>> etc, there are inherent problems, especially with bugtracking, third
>> party ebuilds can cause problems in other gentoo proper ebuilds, 
>Well... I'm a developer of a project. I have submitted via bugzilla
>several bugs of one of the packages I need ( not from the project, just
>a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333 
>ohh, yeah, 2002-05-02 07:28 EST... One year ago...
>The bug is still opened.
>
>I have come back to the new versions of the software... In a completely
>new system, and the ebuild works fine.
>
>
>So, I need to make 1 dependency package, and 6 for the rest of the
>project. I don't want to wait 6 years ( 1 -> 1 year, 2 -> 2 years, and
>so... ) to get my ebuilds in. 
>
>The way: make an ebuild repository...
>The problem: deploy them easily
>
>Yes, I know that I can make a .tar.gz of my port_overlay... But users
>have to do:
>1) Localize URL of the tar.gz
>2) Download it
>3) Move it to /usr/local
>4) Untar it
>5) emerge them
>When using the portage mirror, just 
>1) Add the portage mirror to the list
>2) emerge rsync 
>3) emerge them
>
>> Also say someone write an ebuild (for example oracle, and distributes
>> if in his own tree), this extra ebuild has essentially done nothing
>> for the system or the user. Countless other ebuilds would have to be
>> edited to add support for oracle, patches if required, conf flags, etc. 
>> the user would end up having to maintain lots of duplicate ebuilds
>> in his tree, and run the risk of his getting out of date and a user updating
>> with newer gentoo ebuilds (which dont' have oracle support). 
>> This situation doesn't help anyone.. adding the ebuilds into the main
>> gentoo tree and adding support to ebuilds there is an optimal solution.
>The support should be of the project development team. 

you aren't even listening
the problem is that it isn't easy to know what causes the bug, and i can 
see countless hours being spent by Gentoo devs tracking down a bug that
they find out later is caused by an unrelated ebuild in a 3rd party tree, 
don't tell me it won't happen, I know better.

_Additionally_ you didn't answer my concern about whoever running
the repository having to keep their stuff up to date and in line with 
gentoo proper, it's extra work for him, it's extra risk for his users, 
all around it isn't a clean solution.

>> On the other hand their are no doubt companies which will want
>> to keep proprietary products/ebuilds for themselves, and they can
>> with the current PORTDIR_OVERLAY system, but portage won't 
>> handle distribution manually. 
>ouch... This is the problem.

no, you want to distribute your apps use cvs or rsync outside
of portage, it's simple, you could even cron it, most of us devs
don't keep our local repository up to date with portage, we simply
use cvs up

>> 
>> Summary: I agree with the need for these but it certainly isn't 
>> as simple as you apparently believe. I think portage will probably
>> go in this direction but don't count on it pre portage 2.1
>I hope it
>
probably not until the problems i've said here are addressed. 
noone likes getting bugs, and noone really likes getting bugs
caused by 3rd party apps 

You also didn't mention the problems i addressed wrt metadata 
and caches. This isn't going to happen until those problems
are solved.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[foser]

Joshua Brindle wrote:
<snip>
> 
> you aren't even listening
> the problem is that it isn't easy to know what causes the bug, and i can 
> see countless hours being spent by Gentoo devs tracking down a bug that
> they find out later is caused by an unrelated ebuild in a 3rd party tree, 
> don't tell me it won't happen, I know better.
> 

All these points i brought up in my first mail. Why does everything 
needs saying twice or even thrice (reading trough this thread is one 
deja-vu after the other). (this is not directed @ you method, but at the 
thread as whole)

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Joshua Brindle]

>I was wondering about having several portage trees to allow external 
>distributor having repositories of packages.
>Recently, people have been talking in this list about the difficult proccess 
>of making a deploy of their packages. 

Actually I like this idea and advocated it a while back but it was shot down..
>
>As we know, Debian uses this. Everyone can add a new source of packages to get 
>installed to the system in a clear way. Just by putting deb lines into the 
>sources.list.

irrelavent

>Now the portage have the possibility of using a different portage from 
>PORTDIR_OVERLAY. 
>It could be really useful, if we could use something like it

not PORTDIR_OVERLAY per se, i think something like
/usr/portage/gentoo
/usr/portage/othervendor
/usr/potage/anothervendor

would do, the problem is dependancy tracking and caching.
right now dependancy metadata is generated before rsync
mirrors are updated, this is a tremendous benefit for users 
(nuke your metadata and try an emerge -ep world or emerge -s 
and you'll see what i mean). Having separate trees pretty much 
disallows using server side metadata in this way since the 
metadata wouldn't show inter-tree dependancies.

>In make.conf
>------
>PORT_SOURCES="rsync://source1 rsync://source2" ( it also could be useful if 
>ftp:// is allowed to ( mirror command ) because setup an ftp server is much 
>easier than a rsync one for several reasons like permissions ;) )
>
>PORT_SOURCES_DIR=/usr/local/portages/
>------
>
>So, after making an emerge rsync, we have:
>/usr/portage -> with the official gentoo portage mirror
>/usr/local/portages/source1 -> with the mirror of the source1
>/usr/local/portages/source2 -> with the mirror of the source2
>and so...

yea, this might work too.. 

>So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several 
>trees allowed ).
>
>Is this too hard to implement?
>
>I think it solves a lot of complains about flexibility and edging of Gentoo.
>

this isn't a flexibility issue, it's trivial to download ebuilds and use them, 
write your own, distribute them, maintain your own portdir_overlay
etc, there are inherent problems, especially with bugtracking, third
party ebuilds can cause problems in other gentoo proper ebuilds, 
especially if you are using third party libraries to link against, etc. 
Also say someone write an ebuild (for example oracle, and distributes
if in his own tree), this extra ebuild has essentially done nothing
for the system or the user. Countless other ebuilds would have to be
edited to add support for oracle, patches if required, conf flags, etc. 
the user would end up having to maintain lots of duplicate ebuilds
in his tree, and run the risk of his getting out of date and a user updating
with newer gentoo ebuilds (which dont' have oracle support). 
This situation doesn't help anyone.. adding the ebuilds into the main
gentoo tree and adding support to ebuilds there is an optimal solution.


On the other hand their are no doubt companies which will want
to keep proprietary products/ebuilds for themselves, and they can
with the current PORTDIR_OVERLAY system, but portage won't 
handle distribution manually. 

Summary: I agree with the need for these but it certainly isn't 
as simple as you apparently believe. I think portage will probably
go in this direction but don't count on it pre portage 2.1

Joshua Brindle

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[kikov]

> >As we know, Debian uses this. Everyone can add a new source of packages to get 
> >installed to the system in a clear way. Just by putting deb lines into the 
> >sources.list.
> 
> irrelavent
ehh..... well, it's not irrelevant, IMHO. Debian has good things and bad
things... 
I think that Gentoo is reaching the top of his development model. We
have seen this on thi delaying of recent packages. 

Seemant is setting up the new development model. Maybe, what I'm saying
it's an idea about it.

> >So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several 
> >trees allowed ).
> >
> >Is this too hard to implement?
> >
> >I think it solves a lot of complains about flexibility and edging of Gentoo.
> 
> this isn't a flexibility issue, it's trivial to download ebuilds and use them, 
> write your own, distribute them, maintain your own portdir_overlay
> etc, there are inherent problems, especially with bugtracking, third
> party ebuilds can cause problems in other gentoo proper ebuilds, 
Well... I'm a developer of a project. I have submitted via bugzilla
several bugs of one of the packages I need ( not from the project, just
a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333
ohh, yeah, 2002-05-02 07:28 EST... One year ago...
The bug is still opened.

I have come back to the new versions of the software... In a completely
new system, and the ebuild works fine.


So, I need to make 1 dependency package, and 6 for the rest of the
project. I don't want to wait 6 years ( 1 -> 1 year, 2 -> 2 years, and
so... ) to get my ebuilds in. 

The way: make an ebuild repository...
The problem: deploy them easily

Yes, I know that I can make a .tar.gz of my port_overlay... But users
have to do:
1) Localize URL of the tar.gz
2) Download it
3) Move it to /usr/local
4) Untar it
5) emerge them
When using the portage mirror, just 
1) Add the portage mirror to the list
2) emerge rsync 
3) emerge them

> Also say someone write an ebuild (for example oracle, and distributes
> if in his own tree), this extra ebuild has essentially done nothing
> for the system or the user. Countless other ebuilds would have to be
> edited to add support for oracle, patches if required, conf flags, etc. 
> the user would end up having to maintain lots of duplicate ebuilds
> in his tree, and run the risk of his getting out of date and a user updating
> with newer gentoo ebuilds (which dont' have oracle support). 
> This situation doesn't help anyone.. adding the ebuilds into the main
> gentoo tree and adding support to ebuilds there is an optimal solution.
The support should be of the project development team. 
> On the other hand their are no doubt companies which will want
> to keep proprietary products/ebuilds for themselves, and they can
> with the current PORTDIR_OVERLAY system, but portage won't 
> handle distribution manually. 
ouch... This is the problem.
> 
> Summary: I agree with the need for these but it certainly isn't 
> as simple as you apparently believe. I think portage will probably
> go in this direction but don't count on it pre portage 2.1
I hope it

BR.
Thx

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Fri, Apr 25, 2003 at 09:57:15PM +0200, kikov@fco-gimeno.com wrote:
> Well... I'm a developer of a project. I have submitted via bugzilla
> several bugs of one of the packages I need ( not from the project, just
> a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333
> ohh, yeah, 2002-05-02 07:28 EST... One year ago...
> The bug is still opened.
Go back and read my posting about why many ebuilds don't get into the
tree.
Subject = Re: [gentoo-dev] Ebuilds not getting in :(
Date = Tue, 22 Apr 2003 15:36:55 -0700

If you fix those issues, and fix that ebuild. 
Things to fix:
add SLOT, add KEYWORDS, add IUSE, 'use foo' statement style, use PATCHES
instead of patch+src_unpack, local variable declarations, unnessicary
statement block in src_install, broken homepage URI, ALL documentation
with the package should be installed (manpages and even the guys pgp
key) , einstall instead of 'make install' and most importantly EBUILD
CHANGELOG!!!!!

> I have come back to the new versions of the software... In a completely
> new system, and the ebuild works fine.
Is libcap even actively maintained still? If not and it is not widely
used, then it is not likely to get into the tree at all.

If you resolve all of the above issues, and the package is still widely
used (I want some proof of this), then I'll take the ebuild and maintain
it in portage myself.

Update the bug with your new ebuild and mark the old ones obsolete.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Several portage trees

[Daniel Armyr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I went back and reread the post you mentioned. I feel this should go
into the developer docs. I have read them quite thouroughly, adn most of
~ what you say IS mentioned there, but not in an accessible way. Perhaps
a before-you-submit-checklist at the end of the policy doc? Since you
obviously have quite specific preferences as to how you want the ebuilds
to look, stating these plainy and clearly would be nice.
//Daniel Armyr

| Go back and read my posting about why many ebuilds don't get into the
| tree.
| Subject = Re: [gentoo-dev] Ebuilds not getting in :(
| Date = Tue, 22 Apr 2003 15:36:55 -0700
|
| If you fix those issues, and fix that ebuild.
| Things to fix:
| add SLOT, add KEYWORDS, add IUSE, 'use foo' statement style, use PATCHES
| instead of patch+src_unpack, local variable declarations, unnessicary
| statement block in src_install, broken homepage URI, ALL documentation
| with the package should be installed (manpages and even the guys pgp
| key) , einstall instead of 'make install' and most importantly EBUILD
| CHANGELOG!!!!!
- --
=========================================
daniel.armyr@home.se     f00-dar@f.kth.se

C118 KEVII Hall
1A Kent Ridge Rd S.119224
Singapore                 PGP@pgp.mit.edu
=========================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+qeohhxtTUWLs2lERAgkJAJ9bmKRcyk0P8KA2TgsuJyrxHVgAogCePRJt
3B1LbN/rGqd60CH2+ThfsTk=
=r9lH
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Several portage trees

[Francisco Gimeno]

[-- Attachment #1.1: body text --]
[-- Type: text/plain, Size: 1343 bytes --]

Hi

I was wondering about having several portage trees to allow external 
distributor having repositories of packages.
Recently, people have been talking in this list about the difficult proccess 
of making a deploy of their packages. 

As we know, Debian uses this. Everyone can add a new source of packages to get 
installed to the system in a clear way. Just by putting deb lines into the 
sources.list.

Now the portage have the possibility of using a different portage from 
PORTDIR_OVERLAY. 
It could be really useful, if we could use something like it

In make.conf
------
PORT_SOURCES="rsync://source1 rsync://source2" ( it also could be useful if 
ftp:// is allowed to ( mirror command ) because setup an ftp server is much 
easier than a rsync one for several reasons like permissions ;) )

PORT_SOURCES_DIR=/usr/local/portages/
------

So, after making an emerge rsync, we have:
/usr/portage -> with the official gentoo portage mirror
/usr/local/portages/source1 -> with the mirror of the source1
/usr/local/portages/source2 -> with the mirror of the source2
and so...

So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several 
trees allowed ).

Is this too hard to implement?

I think it solves a lot of complains about flexibility and edging of Gentoo.

BR. 
Byez




[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Several portage trees

[Francisco Gimeno]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1339 bytes --]

Hi

I was wondering about having several portage trees to allow external 
distributor having repositories of packages.
Recently, people have been talking in this list about the difficult proccess 
of making a deploy of their packages. 

As we know, Debian uses this. Everyone can add a new source of packages to get 
installed to the system in a clear way. Just by putting deb lines into the 
sources.list.

Now the portage have the possibility of using a different portage from 
PORTDIR_OVERLAY. 
It could be really useful, if we could use something like it

In make.conf
------
PORT_SOURCES="rsync://source1 rsync://source2" ( it also could be useful if 
ftp:// is allowed to ( mirror command ) because setup an ftp server is much 
easier than a rsync one for several reasons like permissions ;) )

PORT_SOURCES_DIR=/usr/local/portages/
------

So, after making an emerge rsync, we have:
/usr/portage -> with the official gentoo portage mirror
/usr/local/portages/source1 -> with the mirror of the source1
/usr/local/portages/source2 -> with the mirror of the source2
and so...

So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several 
trees allowed ).

Is this too hard to implement?

I think it solves a lot of complains about flexibility and edging of Gentoo.

BR. 
Byez


[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Several portage trees

[foser]

Francisco Gimeno wrote:
> Hi
> 
> I was wondering about having several portage trees to allow external 
> distributor having repositories of packages.
<snip>
> It could be really useful, if we could use something like it

This has been brought up before and I personally do not really like the 
idea too much, i think it makes the distro less reliable as whole if we 
add options like this. People will start using repositories here and 
there and in the end we will get bugreports on ebuilds we never approved 
or even saw (and some ebuilds can have far reaching effects). No, i 
think 'external distributors' should try and go trough the normal 
channels and get their ebuilds Gentoo approved.

> 
> I think it solves a lot of complains about flexibility and edging of Gentoo.
> 

What complaints ? Is it so hard to download an ebuild in put it in your 
local overlay ? The extra step required does make sure you are aware 
that you are using non-approved ebuilds.

- foser



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Peter Fein]

On Fri, 25 Apr 2003 14:36:53 +0200
foser <foser@foser.dyn.warande.net> wrote:

> Francisco Gimeno wrote:
> > Hi
> > 
> > I was wondering about having several portage trees to allow external 
> > distributor having repositories of packages.
> <snip>
> > It could be really useful, if we could use something like it
> 
> This has been brought up before and I personally do not really like the 
> idea too much, i think it makes the distro less reliable as whole if we 
> add options like this. People will start using repositories here and 
> there and in the end we will get bugreports on ebuilds we never approved 
> or even saw (and some ebuilds can have far reaching effects). No, i 
> think 'external distributors' should try and go trough the normal 
> channels and get their ebuilds Gentoo approved.

I think a note saying "DON"T DO THIS UNLESS YOU REALLY KNOW WHAT YOU'RE DOING",
as is done elsewhere would suffice.  Given the recent volume on ebuild approval,
that's not much of an counter-argument.  I agree that inclusion in Gentoo-proper
is a worthy goal - but as a user, not being restricted to blessed packages
should be my choice (and of course, no one's under any obligation to support any
of this to begin with, but it's worth discussing). Maybe I'm less scared of
stability issues running Gentoo on a home box that could erupt into flames
without causing me much distress, but this should be a matter of choice, rather
than a policy enforced by software.  Such a scheme may actually speed up package
acceptance, as it provides a wider test base prior to inclusion.

> > 
> > I think it solves a lot of complains about flexibility and edging of Gentoo.
> > 
> 
> What complaints ? Is it so hard to download an ebuild in put it in your 
> local overlay ? The extra step required does make sure you are aware 
> that you are using non-approved ebuilds.

I'd be aware I'd be using non-approved ebuilds if I set those vars in the first
place & portage warned/notified me which repository it was installing from. 
This architecture rocks - restricting it to approved packages only deprives
folks of a really great tool (wow, I'm sounding awfully "software wants to be
free" today...).

--Pete

-- 
Peter Fein
pfein@pobox.com
773-575-0694

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[foser]

Peter Fein wrote:
> I think a note saying "DON"T DO THIS UNLESS YOU REALLY KNOW WHAT YOU'RE DOING",
> as is done elsewhere would suffice.  

I disagree, we say that with certain things right now, still users do 
use it without obviously knowing what they're doing and do file bugs 
about it. This is experience speaking.

> Given the recent volume on ebuild approval,
> that's not much of an counter-argument. 

That's not much of an argument either. The thread agreed with the fact 
that there were some problems, but they are being worked on. Besides, i 
know of a lot of open ebuild requests that are still not submitted for 
whole other reasons (unstable versions, some old unsupported stuff etc.) 
and probably never will.

> I agree that inclusion in Gentoo-proper
> is a worthy goal - but as a user, not being restricted to blessed packages
> should be my choice (and of course, no one's under any obligation to support any
> of this to begin with, but it's worth discussing).

You stil have the choice, the main point is i think we shouldn't promote 
it. 'restricting' users to 'blessed' packages is a guarantee for the 
best possible experience we can offer, there are ways around it for the 
bold or whatever you want to call them. Anyway, we still don't restrict 
them, every serious ebuild submission is considered.

> Maybe I'm less scared of
> stability issues running Gentoo on a home box that could erupt into flames
> without causing me much distress, but this should be a matter of choice, rather
> than a policy enforced by software.  Such a scheme may actually speed up package
> acceptance, as it provides a wider test base prior to inclusion.

Or hamper ebuild acceptance (may be better terminology), because people 
don't feel the need to get it into the Gentoo bugzilla anymore. And 
testing without feedback hasn't much effect. Testing of non-gentoo 
packages is ignored, we don't support ebuilds not in the tree.

> 
> I'd be aware I'd be using non-approved ebuilds if I set those vars in the first
> place & portage warned/notified me which repository it was installing from. 
> This architecture rocks - restricting it to approved packages only deprives
> folks of a really great tool (wow, I'm sounding awfully "software wants to be
> free" today...).

More vars, more warnings, increased complexity : it makes great tools 
less and less usable over time. New features should be considered 
carefully if they really add something substantial, in my opinion that's 
not the case here.

There is no restriction imposed, 'depriving' people of easily accessible 
major amounts of low quality, possibly conflicting ebuilds is not a bad 
thing per se.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Todd Berman]

On Fri, 25 Apr 2003, Peter Fein wrote:

> > >
> > > I think it solves a lot of complains about flexibility and edging of Gentoo.
> > >
> >
> > What complaints ? Is it so hard to download an ebuild in put it in your
> > local overlay ? The extra step required does make sure you are aware
> > that you are using non-approved ebuilds.
>
> I'd be aware I'd be using non-approved ebuilds if I set those vars in the first
> place & portage warned/notified me which repository it was installing from.
> This architecture rocks - restricting it to approved packages only deprives
> folks of a really great tool (wow, I'm sounding awfully "software wants to be
> free" today...).

I'd have to disagree with you here, I think it would be a bad idea to have
something like this set up. What would happen if 'proper' gentoo has
package foo version 1.0 and it depends on package bar 0.5, and breaks with
anything newer. Then one of your new rsync's puts in package bar 0.7 and
breaks the 'official' foo package for you. Just seems like a lose lose
situation.

The advantage of gentoo and portage is your are being told that these
packages SHOULD work together, and if they dont, put in a bug, and we will
figure out why.

And remember, if you need a new package, just install it from source, its
not that hard :)

--Todd

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Peter Fein]

On Fri, 25 Apr 2003 14:23:08 -0400 (EDT)
Todd Berman <tberman@insideyou.org> wrote:

> 
> 
> On Fri, 25 Apr 2003, Peter Fein wrote:
> 
> > > >
> > > > I think it solves a lot of complains about flexibility and edging of
> > > > Gentoo.
> > > >
> > >
> > > What complaints ? Is it so hard to download an ebuild in put it in your
> > > local overlay ? The extra step required does make sure you are aware
> > > that you are using non-approved ebuilds.
> >
> > I'd be aware I'd be using non-approved ebuilds if I set those vars in the
> > first place & portage warned/notified me which repository it was installing
> > from. This architecture rocks - restricting it to approved packages only
> > deprives folks of a really great tool (wow, I'm sounding awfully "software
> > wants to be free" today...).
> 
> I'd have to disagree with you here, I think it would be a bad idea to have
> something like this set up. What would happen if 'proper' gentoo has
> package foo version 1.0 and it depends on package bar 0.5, and breaks with
> anything newer. Then one of your new rsync's puts in package bar 0.7 and
> breaks the 'official' foo package for you. Just seems like a lose lose
> situation.

Shouldn't it be <=bar-0.5'd then anyway?  Just thinkin...

> The advantage of gentoo and portage is your are being told that these
> packages SHOULD work together, and if they dont, put in a bug, and we will
> figure out why.

Hmm, I hadn't thought of it like that - for me, it's the customization plus the
automation of a lot of the tedious stuff - dependencies, downloading, etc..

> And remember, if you need a new package, just install it from source, its
> not that hard :)

You're right, it's not so bad.  Though at work, I've got to deal with compiling
stuff on a half-maintained Solaris x86 platform.  I haven't built anything
remotely complex in less than 3 days - it's skewered my perspective... ;)

--Pete

-- 
Peter Fein
pfein@pobox.com
773-575-0694

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[George Shapovalov]

On Friday 25 April 2003 08:10, Peter Fein wrote:
> > > I was wondering about having several portage trees to allow external
> > > distributor having repositories of packages.
> I think a note saying "DON"T DO THIS UNLESS YOU REALLY KNOW WHAT YOU'RE
> DOING", as is done elsewhere would suffice.  Given the recent volume on
> ebuild approval, that's not much of an counter-argument.  I agree that
> inclusion in Gentoo-proper is a worthy goal - but as a user, not being
> restricted to blessed packages should be my choice (and of course, no one's
> under any obligation to support any of this to begin with, but it's worth
> discussing). Maybe I'm less scared of stability issues running Gentoo on a
> home box that could erupt into flames without causing me much distress, but
> this should be a matter of choice, rather than a policy enforced by
> software.  Such a scheme may actually speed up package acceptance, as it
> provides a wider test base prior to inclusion.
While I agree that providing the option for users to easily get a hold on 
"unapproved" ebuilds is nice and goes along the lines of gentoo phylosophy 
(to allow user break his system as he wishes ;), provided the usual 
disclamer) I do not think separate branch is an answer or even a good idea at 
all.
Granted, debian and pretty much every large binary distribution have brancesh, 
but bear in mind that they are exactly this: binary distribution. We are 
talking about much stricter (and in that respect contradicting) goals and 
central amintaince of these branches. Now, because of higher flexibility 
central maintaince is not really an option in our case and actually goes 
completely against the purpose of this proposed branch...
(I personally don't thunk we need branches even for specialized stuff. We have 
a very flexible mechanism - profiles - in place that allows to form a very 
specialized distribution off the general tree)

So, lets talk about user-land.
If you are talking about this seriously, you should consider the amount of 
ebuilds you will have to sotre and process and what work is involved and what 
kind of "service" are you going to provide. 
My estimate is that you can easily get 500+ ebuilds if you just go through 
bugzilla (I just quickly searched for "new" in the subject) and eventually 
the number will hit the range of thousands. So, do you want to just pile them 
all up in a loooong list? You will have to do some kind of processing and 
arrangement on all these ebuilds.

Lets see: Joe User wants to see what's available in this "freaky" stuff he 
heard so much about on some topic. I can imagine him going like that:
"Oh, there was some noise recently on creating that freaky-branch, should be 
cool to see what's in there. What? Its like 1000+ ebuilds there, how am I 
going to make sence of it ever. Did these guys set-up a search engine yet? 
Fortunately they did (because it's been half a year into this  project 
already :)). Well, I found some stuff, I'ts good they also copied all the 
bugzilla correspondence here, so that I can have some idea on what's the 
status of this ebuild! But wait, I remember somebody announcing a really neat 
thing few weeks ago on -dev, why don't I see it here. How can some people be 
so inconsiderable as not to use this freaky-branch stuff? Sure I know its in 
bugzilla, but it is sooo boring to go there and search, even though not any 
harder..."

Sorry for this improvisation, too much imagination I guess :).

Anyway, my point is, if you want to make this even remotely usefull you will 
have to provide quite a bit of service other than just piling ebuilds up on 
some page. What's more, I think it is quite essentiall to provide a 
possibility of feedback and appropriate ebuild tagging (unless you want to 
test all these ebuilds for stability and correctness yourelf, but in this 
case I will start quietly pointing that rectuiters address to you ;)). And 
somehow all this reminds me of bugs.gentoo.org already ;).

As you can see I have strong feelings about this type of branching, I hope 
this serves as an explanation. I apologise to anybody who thinks I was too 
harsh in this comment.

So, what instead? Can I point you and everybody interested in the direction of 
#1523 again ;)?
Sure, that bug is lengthy and quite involved, so not many people actually get 
through. However I do not see any easy way to go about it. Yes, it *is* 
complex, just what I tried to briefly illustrate and I did not even mention 
any security considerations (without which it's not gonna be approved by 
majority of developers), and possible and IMHO quite required automation..

Yes, that bug was around for like ages already. But if you read it carefully 
you will realise, that some major infrastracture changes have already taken 
place (most of that was written when there were no KEYWORDS and 
gentoo-stable/stats for example). We are undergoing another infrastructure 
rewamp atm and as soon as it gets near completion I will start updating that 
bug again (it doesn't make sence to do so before some organizational issues 
are finalized).

On a final note I just want to solicit some patience and faith in developers. 
We do acknowledge the problem and we are trying to address it. Don't forget 
that we are talking about core infrastructure changes here and it always 
takes time, especially if we want to stay alive during them :).

Post final note :). As always, discussion and contributions in other forms are 
wellcome!

George

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Peter Fein]

On Fri, 25 Apr 2003 12:02:03 -0700
George Shapovalov <george@gentoo.org> wrote:

> On Friday 25 April 2003 08:10, Peter Fein wrote:


<much liberal snipping>

> Lets see: Joe User wants to see what's available in this "freaky" stuff he 
> heard so much about on some topic. I can imagine him going like that:
> "Oh, there was some noise recently on creating that freaky-branch, should be 

This made me smile                                    ^^^^^^^^^^^^^.

> cool to see what's in there. What? Its like 1000+ ebuilds there, how am I 
> going to make sence of it ever. Did these guys set-up a search engine yet? 

I feel this way about the regular tree sometimes, let alone with a possible
forest.

> As you can see I have strong feelings about this type of branching, I hope 
> this serves as an explanation. I apologise to anybody who thinks I was too 
> harsh in this comment.
> 
> So, what instead? Can I point you and everybody interested in the direction of
> #1523 again ;)?

I just reread it and it made sense this time. ;)  It's a much better solution.

> On a final note I just want to solicit some patience and faith in developers. 
> We do acknowledge the problem and we are trying to address it. Don't forget 
> that we are talking about core infrastructure changes here and it always 
> takes time, especially if we want to stay alive during them :).

Sorry if I was overeager - I'm quite appreciative of the work y'all do.  Please
stay alive. ;)

> Post final note :). As always, discussion and contributions in other forms are
> wellcome!

My carrier pigeon will be departing shortly. ;)  Happy Friday!

-- 
Peter Fein
pfein@pobox.com
773-575-0694

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Joseph Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Apr 25, 2003 at 10:10:49AM -0500, Peter Fein wrote:
> > This has been brought up before and I personally do not really like the 
> > idea too much, i think it makes the distro less reliable as whole if we 
> > add options like this. People will start using repositories here and 
> > there and in the end we will get bugreports on ebuilds we never approved 
> > or even saw (and some ebuilds can have far reaching effects). No, i 
> > think 'external distributors' should try and go trough the normal 
> > channels and get their ebuilds Gentoo approved.
> 
> I think a note saying "DON"T DO THIS UNLESS YOU REALLY KNOW WHAT YOU'RE
> DOING", as is done elsewhere would suffice.  Given the recent volume on
> ebuild approval, that's not much of an counter-argument.  I agree that
> inclusion in Gentoo-proper is a worthy goal - but as a user, not being
> restricted to blessed packages should be my choice (and of course, no
> one's under any obligation to support any of this to begin with, but
> it's worth discussing). Maybe I'm less scared of stability issues
> running Gentoo on a home box that could erupt into flames without
> causing me much distress, but this should be a matter of choice, rather
> than a policy enforced by software.  Such a scheme may actually speed up
> package acceptance, as it provides a wider test base prior to inclusion.

I'll begin by saying I have some issues with Debian these days.  Take my
opinions with a Syberian salt mine if you like.

I must warn that although Debian's preferred package system (but not its
only one) happens to support more than one source for packages, these
packages almost all are made by Debian developers or people who would be
developers if not for the "internal issues" which have so turned me off
from that project.  Nearly all of the packages in question are intended to
be part of the Debian distribution eventually.

Gentoo provides a mechanism for the most common thing non-Debian sources
are used for: things which really aren't ready for the average user, even
in unstable.  If it isn't ready, Gentoo will simply keep it masked.  The
adventurous will unmask it by hand.

The other thing it's used for is for in Debian is a place to put things
that Debian will not accept because they're all a bunch of spineless
cowards who don't want to risk annoying the media conglomerates and
similar.  Everything Debian wouldn't take that I've actually wanted is in
Gentoo already, so I doubt that will be a big deal.


I will say that Debian's size is one of its biggest problems.  You just
can't make 11,000 packages stable on 12 different architectures for a
stable release.  It's less of a problem for Gentoo since we're dealing
with source here, but it's still significantly difficult.  To Gentoo's
credit, the portage tree operates already the way Debian's package pool
was supposed to work as designed by a few of us Debianites (I was among
them) as far back as 1998 or so to cope with Debian's size/stability
issues.  Five years later, Debian's package pools still don't work the way
we specced it.  Gentoo's system does.

Guess which Linux dist I'm writing this email from?  ;)

- -- 
Joseph Carter <knghtbrd@efn.org>                Do not write in this space
 
"I've never had major knee surgery on any other part of my body."
        -- Winston Bennett, University of Kentucky basketball forward
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: 1024D/20F62261F1857A3E79FC44F98FF7D7A3DCF9DAB3

iEYEARECAAYFAj6qL9AACgkQj/fXo9z52rPk1ACfYkm81URuxUxiceraAvHzghp9
OJkAn3K8jRddoRI76PDia1X3Z+oC4+Pk
=ngVk
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list