| View previous topic :: View next topic |
| Author |
Message |
Conan
Guru
Joined: 02 Nov 2004
Posts: 360
|
 Posted: Wed Dec 20, 2006 10:29 pm Post subject: |
 |
|
Okay, I read the entirety of the thread.
I understand what you are asking now (I think).
The answer is basically what I said in my last post. Overlays as a repository for unsupported software is kind of a new idea that came about fairly recently. This came about with overlays.gentoo.org
PORTDIR_OVERLAY had been a more local thing, allowing users to patch an ebuild or two.
Without overlays.g.o the developers would have to host the overlay on their personal infrastructure. This caused it to not be a very good alternative, and therefore software was added to portage. |
|
| Back to top |
|
 |
Ateo
Advocate
Joined: 02 Jun 2003
Posts: 2021
Location: Republic of California
|
| Posted: Wed Dec 20, 2006 10:50 pm Post subject: |
|
|
| Conan wrote: | Okay, I read the entirety of the thread.
I understand what you are asking now (I think).
The answer is basically what I said in my last post. Overlays as a repository for unsupported software is kind of a new idea that came about fairly recently. This came about with overlays.gentoo.org
PORTDIR_OVERLAY had been a more local thing, allowing users to patch an ebuild or two.
Without overlays.g.o the developers would have to host the overlay on their personal infrastructure. This caused it to not be a very good alternative, and therefore software was added to portage. |
I don't really need for you to explain what overlay is, but thanks. I know what function it serves. But that is *not* the point. The point is unsupported software should not be in portage. Anything that resides in the heart of Gentoo should be supported.
Correct me if I am wrong, but doesn't the arch ~x86 define supported packages under 'testing' phases (whether it's the ebuild or the actual source that's under testing is transparent to me, the end user)? Expect it to perhaps break your system and be ready to hit bugzilla to either find fixes or report a bug. But the purpose is to help stabilize software.
I do believe hard masking unsupported packages would be a good alternative. But even then, hard masked packages are hard masked because they aren't ready for the public suggesting there is some level of support for hard masked packages, right? |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Thu Dec 21, 2006 8:33 am Post subject: |
|
|
The various patchsets are there since years, longer than any of the things like overlays.gentoo.org or layman exist.
Back in the days there was no (better) possibility for the kernel guys to have the different patchsets accessible by the users but put them into portage. Thats why there is the clear statemen in the kernel guide | Gentoo Linux Kernel Guide wrote: | | These kernels are provided as a courtesy only and the various patch sets are not supported by the Gentoo team. |
Looking at today the 'better' solution would be to have everything but the supported patchsets moved to an overlay, i believe thats your point, correct?
But ... as you might know, nothing lasts longer than a 'temporary solution' (which the kernel guys took years ago).
Nearly sure it'll create a lot of headaches for the devs, raise a ton of DUP-threads and alike if someone would today take the decission to move the patchsets to an overlay. Handling this takes _a lot_ of time which noone has.
Up to now the above quote was enough but in theory you are correct. Well, do _you_ (Ateo) have the time to help out and do the (pre)-support for everything (bug handling, answer forum threads, move/dup both of them, be available in IRC for the same, etc) which will come up when it would be changed?
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
Ateo
Advocate
Joined: 02 Jun 2003
Posts: 2021
Location: Republic of California
|
| Posted: Thu Dec 21, 2006 5:10 pm Post subject: |
|
|
| Think4UrS11 wrote: | | Up to now the above quote was enough but in theory you are correct. Well, do _you_ (Ateo) have the time to help out and do the (pre)-support for everything (bug handling, answer forum threads, move/dup both of them, be available in IRC for the same, etc) which will come up when it would be changed? |
I am indifferent about kernel being in Portage for the sake of convenience. Things should not be in the official portage tree for the sake of convenience. If that is the case, then there should be support.
To answer you question above, sure, I'd be willing to help out with the exception of IRC, well, because I don't like IRC. Just keep in mind that I am not a developer in any way.
| Think4UrS11 wrote: | | Looking at today the 'better' solution would be to have everything but the supported patchsets moved to an overlay, i believe thats your point, correct? |
Where it is moved to is of no concern to me. But you are correct, moving all unsupported software (not just kernel patchsets) out of Portage and somewhere else is my point. |
|
| Back to top |
|
|
antarus
Retired Dev
Joined: 16 May 2005
Posts: 77
Location: Michigan
|
| Posted: Thu Dec 21, 2006 11:06 pm Post subject: |
|
|
| Ateo wrote: | | Think4UrS11 wrote: | | Up to now the above quote was enough but in theory you are correct. Well, do _you_ (Ateo) have the time to help out and do the (pre)-support for everything (bug handling, answer forum threads, move/dup both of them, be available in IRC for the same, etc) which will come up when it would be changed? |
I am indifferent about kernel being in Portage for the sake of convenience. Things should not be in the official portage tree for the sake of convenience. If that is the case, then there should be support. |
Why not? It is clearly labeled "unsupported". Why must everything be so clear cut? Then you can make this generalization about 'how every package in portage will have support', which will never be true. Some people will work on your problems, and some people are just here to maintain ebuilds and will send you upstream. Thats how it is.
| Ateo wrote: |
| Think4UrS11 wrote: | | Looking at today the 'better' solution would be to have everything but the supported patchsets moved to an overlay, i believe thats your point, correct? |
Where it is moved to is of no concern to me. But you are correct, moving all unsupported software (not just kernel patchsets) out of Portage and somewhere else is my point. |
Are you volunteering to do the moving? I maintain a few random packages (esearch, nis-utils, fluxbox) but I don't "support" them. If there is a problem with the ebuild I'll fix it; if there is a problem with esearch I'll fix it because upstream is dead. If there is a problem with nis-utils I probably won't give a crap because I'm not using it at work anymore; fluxbox I'll probably look for your problem in their bugzilla equivilant and or look for a patch in fluxbox svn. But I'm not going to sit here and debug your problem (unless you catch me in a good mood, which happens, just ask peeps in #gentoo).
The problem is you can't standardize what 'support' is. E17 is 'supported'; although vapier's definition of support probably isn't yours (only file a bug with a patch). But you can probably pry the e17 ebuilds from his cold dead fingers.
The minimum level of support for a package in the tree is 'ebuild level support', if the ebuild has a problem we will fix it. Many developers go far beyond that requirement (think paludis, or portage, or esearch); much of the time it is because the developers in question are upstream for the given packages and perform both roles (application support and ebuild support).
This is not to say that you cannot get application level support, but it is not required. Once a maintainer determines it's not a gentoo related problem, they are free to send you elsewhere. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Dec 22, 2006 6:23 am Post subject: |
|
|
| 6thpink wrote: | Still it is true that there is a serious inconsistency here.
For example, if I post somewhere in the Desktop Environment section about gtk segfaults, gimp errors or general questions not related to the ebuild, but to things that are part of the app itself (upstream) I will certainly always receive support. In most cases the bug/problem/doubt is reproducible in any other distro the same, since it is not a question about an specific gentoo pacth or an ebuild problem.
<snip>
I think that this inconsistency in the behaviour is what drives mad too much users. And to a certain degree I agree  that really unsupported stuff should be out of portage.
Otherwise, if the support is just for the ebuild, and not the software, all the forums would be empty, but the portage one.
Maybe to create a section called "Alternative kernel patchsets" in these forums would help as well. |
++ to all that.
| antarus wrote: | | Are you volunteering to do the moving? |
Yeah, I am 
| Quote: | The problem is you can't standardize what 'support' is. E17 is 'supported'; although vapier's definition of support probably isn't yours (only file a bug with a patch). But you can probably pry the e17 ebuilds from his cold dead fingers.
The minimum level of support for a package in the tree is 'ebuild level support', if the ebuild has a problem we will fix it. Many developers go far beyond that requirement (think paludis, or portage, or esearch); much of the time it is because the developers in question are upstream for the given packages and perform both roles (application support and ebuild support).
This is not to say that you cannot get application level support, but it is not required. Once a maintainer determines it's not a gentoo related problem, they are free to send you elsewhere. |
I accept that last statement, but I really do not agree that one cannot standardise support. I believe a good definition of what the standard should be was already given with the result that:
| 6thpink wrote: | | I think that this inconsistency in the behaviour is what drives mad too much users. And to a certain degree I agree that really unsupported stuff should be out of portage. |
Why not just make it policy that if it's unsupported, it's in an overlay? It wouldn't be hard to find those pkgs after all, and maybe we could automate it after we've done the kernel patches. |
|
| Back to top |
|
|
antarus
Retired Dev
Joined: 16 May 2005
Posts: 77
Location: Michigan
|
| Posted: Fri Dec 22, 2006 5:02 pm Post subject: |
|
|
| steveL wrote: |
Why not just make it policy that if it's unsupported, it's in an overlay? It wouldn't be hard to find those pkgs after all, and maybe we could automate it after we've done the kernel patches. |
Because I don't think that policy would be adhered to. |
|
| Back to top |
|
|
Ateo
Advocate
Joined: 02 Jun 2003
Posts: 2021
Location: Republic of California
|
| Posted: Fri Dec 22, 2006 5:34 pm Post subject: |
|
|
I don't expect a gentoo dev to fully, 100% support say.... xchat, for example. I understand that the ebuild is made and that if there are problems with the ebuild, gentoo devs fix it. If it happens to be a bug within xchat, I understand that that is where your support stops and you send it upstream to xchat. So as you can see, gentoo support does have a fine line.
But when there is no support at all for a packages other than "we don't support it, it's not our issues, be gone" is not acceptable and is poor practice. Sounds like an AOL tech pawning off users to their Teclo. I expect a certain level of support when I install an ebuild since support has been offered. If you think it is too much for me to expect, well, not much I can do about that. But that's what I expect from a mature distro. Stability, consistency and support for their packages.
All that talk about overlay and the like and how much of a hassle it is is just nonsense. I just don't understand all this talk about overlay being a headache for kernel patchsets as mentioned above. I've been using my overlay for various ebuilds for the last 4 years. I can't recall any serious issues.
As a final note, of course I'd be willing to help with any changes. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Dec 24, 2006 2:43 pm Post subject: |
|
|
| antarus wrote: | | steveL wrote: |
Why not just make it policy that if it's unsupported, it's in an overlay? It wouldn't be hard to find those pkgs after all, and maybe we could automate it after we've done the kernel patches. |
Because I don't think that policy would be adhered to. |
But if we have a system that automatically moves software marked as unsupported into an `Unsupported' overlay (possibly multiple according to herd) then it wouldn't matter whether people adhere to it or not. The system would enforce the policy. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Sun Dec 24, 2006 2:58 pm Post subject: |
|
|
steveL,
Keep in mind that your are a part of the 'we' here.
Care to contribute a patch ?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Dec 27, 2006 9:18 pm Post subject: |
|
|
| NeddySeagoon wrote: | Keep in mind that your are a part of the 'we' here.
Care to contribute a patch ? |
I'll happily contribute code, if you can tell me exactly what I should change, and who can answer my questions about the current code. In this current instance I thought we were talking about moving kernel patches from the portage tree. What would I be patching there? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Wed Dec 27, 2006 9:57 pm Post subject: |
|
|
steveL,
You would be automating the process so that the moved code base was transparent to users and did not need developers to do anything extra either.
Read up the gentoo develpers docs at http://www.gentoo.org/doc/en/list.xml. They may giev you an idea to to talk to too.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jan 01, 2007 5:16 am Post subject: |
|
|
| NeddySeagoon wrote: | You would be automating the process so that the moved code base was transparent to users and did not need developers to do anything extra either.
Read up the gentoo develpers docs at http://www.gentoo.org/doc/en/list.xml. They may giev you an idea to to talk to too. |
I've had a look at that but TBH i think this would need oversight from someone else. I'd happily contribute, but I don't know what's involved in moving a load of stuff in the tree; the idea is to automate it after we've done it manually.
Happy New Year BTW  |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Jan 03, 2007 6:54 am Post subject: |
|
|
Well, I've been thinking about it, and this sounds like a good project to work on; there are good reasons to do it, and it'd hopefully improve things for others- especially if we can find a way to automate the process. (If we can't, well sh*t happens- will still have learnt a thing or 3 ;)
So, Ateo are you still up for helping as well? If there's two of us to work on this, both learning of course, it should be easier. Antarus- you seem to know loads about this (treecleaner and all) so would you mind overseeing us?
edit: tired, missed out a couple of words. |
|
| Back to top |
|
|
antarus
Retired Dev
Joined: 16 May 2005
Posts: 77
Location: Michigan
|
| Posted: Fri Jan 05, 2007 3:16 am Post subject: |
|
|
| steveL wrote: | Well, I've been thinking about it, and this sounds like a good project to work on; there are good reasons to do it, and it'd hopefully improve things for others- especially if we can find a way to automate the process. (If we can't, well sh*t happens- will still have learnt a thing or 3 
So, Ateo are you still up for helping as well? If there's two of us to work on this, both learning of course, it should be easier. Antarus- you seem to know loads about this (treecleaner and all) so would you mind overseeing us?
edit: tired, missed out a couple of words. |
Well first you define your task:
| steveL wrote: | | But if we have a system that automatically moves software marked as unsupported into an `Unsupported' overlay (possibly multiple according to herd) then it wouldn't matter whether people adhere to it or not. The system would enforce the policy. |
1. Figure out how to mark software as unsupported.
2. Decide how to set up the overlays (1 or many, by herd or by some other specifier)
3. Write a script that searches for software marked by (1)
4. Iterate over packages marked for unsupported and copy them into an overlay.
4a. If the copy succeeds, delete the package from cvs with a relevant changelog.
4b. If the copy fails, continue with next package, but log the failure.
Generally people dislike any kind of automated CVS scripts (besides simple shell constructs like 'commit all of kde' or something similar for large packages). Someone must be responsible for the actions of said script.
The flaw in this is that (1) is still a manual process. The maintainer has to mark the software as unsupported in the first place, and really I don't think this use case is as prevelant as you may think.
So earlier in the thread when I say "the policy won't be followed" this is what I mean; there is no way to detect unsupported software automatically. As a maintainer I could just add random packages and disclaim support for them; unless someone else with commit access cares enough to change it (and most are busy enough with their own packages) it will remain 'supported'. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Jan 05, 2007 9:34 am Post subject: |
|
|
| antarus wrote: | | Generally people dislike any kind of automated CVS scripts (besides simple shell constructs like 'commit all of kde' or something similar for large packages). Someone must be responsible for the actions of said script. |
Well I guess that'd be me if I wrote it, but politically it'd be better if you were ;)
| Quote: | The flaw in this is that (1) is still a manual process. The maintainer has to mark the software as unsupported in the first place, and really I don't think this use case is as prevelant as you may think.
So earlier in the thread when I say "the policy won't be followed" this is what I mean; there is no way to detect unsupported software automatically. As a maintainer I could just add random packages and disclaim support for them; unless someone else with commit access cares enough to change it (and most are busy enough with their own packages) it will remain 'supported'. |
I hear you- I'm sure maintainers won't - especially if they've left :) I just see it as an extension of treecleaners, so when people complain, you can just say: look that POS pkg is in the so-overlay. Get it from there, and done. No xmms prob (had to rub it in ;)
TBH I think if the frozen tree thing you were talking about is still on the way, then things will also get a lot easier then. Please tell me I'm right.. |
|
| Back to top |
|
|
antarus
Retired Dev
Joined: 16 May 2005
Posts: 77
Location: Michigan
|
| Posted: Sat Jan 06, 2007 9:54 am Post subject: |
|
|
| steveL wrote: | | antarus wrote: | | Generally people dislike any kind of automated CVS scripts (besides simple shell constructs like 'commit all of kde' or something similar for large packages). Someone must be responsible for the actions of said script. |
Well I guess that'd be me if I wrote it, but politically it'd be better if you were
| Quote: | The flaw in this is that (1) is still a manual process. The maintainer has to mark the software as unsupported in the first place, and really I don't think this use case is as prevelant as you may think.
So earlier in the thread when I say "the policy won't be followed" this is what I mean; there is no way to detect unsupported software automatically. As a maintainer I could just add random packages and disclaim support for them; unless someone else with commit access cares enough to change it (and most are busy enough with their own packages) it will remain 'supported'. |
I hear you- I'm sure maintainers won't - especially if they've left I just see it as an extension of treecleaners, so when people complain, you can just say: look that POS pkg is in the so-overlay. Get it from there, and done. No xmms prob (had to rub it in
TBH I think if the frozen tree thing you were talking about is still on the way, then things will also get a lot easier then. Please tell me I'm right.. |
OK we are hopping around USE cases again. This all started from the kernel team and convenience ebuilds and their lack of application level support. But they are maintained by the kernel team at the ebuild level; thats what being in the tree is about. This is USE case one, where I'd wager that the kernel team will never follow the new policy (because they never would have placed the ebuilds in the tree in the first place).
The second USE case is a package somewhat like XMMS. Either:
A. The package has no active maintainer and no active herd (and thus falls to the maintainer-needed alias and the Package Wrangler herd) OR
B. The package has an active maintainer who wishes to remove application level support.
C. The package has an active maintainer who wishes to remove ebuild level support.
Bugs for package A are covered by maintainer-needed, potentially treecleaners, and potentially package wranglers.
Bugs for package C are covered by removing the package unless the users find a proxy maintainer to continue the ebuild level support (what we have established as the 'minimum')
Bugs for package B go to the maintainer until the maintainer concludes it's not a Gentoo specific problem, in which case they go upstream.
Your wish (as I see it) is to have all the packages that fit into B put into an overlay maintained by a developer (for ebuild support). In which case all the packages in the tree would have both ebuild and application support, things with just ebuild support go in a developer overlay, and things with no support go in a third party overlay. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 06, 2007 4:28 pm Post subject: |
|
|
| antarus wrote: | | steveL wrote: | | antarus wrote: | | Generally people dislike any kind of automated CVS scripts (besides simple shell constructs like 'commit all of kde' or something similar for large packages). Someone must be responsible for the actions of said script. |
Well I guess that'd be me if I wrote it, but politically it'd be better if you were
| Quote: | The flaw in this is that (1) is still a manual process. The maintainer has to mark the software as unsupported in the first place, and really I don't think this use case is as prevelant as you may think.
So earlier in the thread when I say "the policy won't be followed" this is what I mean; there is no way to detect unsupported software automatically. As a maintainer I could just add random packages and disclaim support for them; unless someone else with commit access cares enough to change it (and most are busy enough with their own packages) it will remain 'supported'. |
I hear you- I'm sure maintainers won't - especially if they've left I just see it as an extension of treecleaners, so when people complain, you can just say: look that POS pkg is in the so-overlay. Get it from there, and done. No xmms prob (had to rub it in
TBH I think if the frozen tree thing you were talking about is still on the way, then things will also get a lot easier then. Please tell me I'm right.. |
OK we are hopping around USE cases again. This all started from the kernel team and convenience ebuilds and their lack of application level support. But they are maintained by the kernel team at the ebuild level; thats what being in the tree is about. This is USE case one, where I'd wager that the kernel team will never follow the new policy (because they never would have placed the ebuilds in the tree in the first place).
The second USE case is a package somewhat like XMMS. Either:
A. The package has no active maintainer and no active herd (and thus falls to the maintainer-needed alias and the Package Wrangler herd) OR
B. The package has an active maintainer who wishes to remove application level support.
C. The package has an active maintainer who wishes to remove ebuild level support.
Bugs for package A are covered by maintainer-needed, potentially treecleaners, and potentially package wranglers.
Bugs for package C are covered by removing the package unless the users find a proxy maintainer to continue the ebuild level support (what we have established as the 'minimum')
Bugs for package B go to the maintainer until the maintainer concludes it's not a Gentoo specific problem, in which case they go upstream.
Your wish (as I see it) is to have all the packages that fit into B put into an overlay maintained by a developer (for ebuild support). In which case all the packages in the tree would have both ebuild and application support, things with just ebuild support go in a developer overlay, and things with no support go in a third party overlay. |
Disclaimer: I've had a really stressful couple of weeks, and I'm completely knackered (I have just had a good sleep) so if I'm not understanding things, don't get angry, just ignore it and put me right.
I'm feeling a bit out of my depth with the USE cases and all that- I wasn't the op, so it's not my wish in particular. My understanding was that certain pkgs are in the tree which everyone one should know are unsupported, and it seems like there's a consensus that cleaning them out of the tree would be a good idea. People get annoyed however when pkgs disappear from the tree which they still use. This isn't necessarily the marked-unsupported ones, but pkgs that typically have died upstream (like XMMS).
So the marked-unsupported ones are, I think, the ones you're calling ebuild-level support, in that the ebuilds work, but there's no actual support or bug-handling if it doesn't work. Bug handling includes fixing and passing upstream, basically gentoo are effectively involved in the development process of the pkg. That would be the application-level support, as I understand it.
The moving of pkgs into an overlay is to allow people to continue using them. Why they can't just copy the ebuilds and keep adjusting the version numbers, or even heaven forbid, compile the source themselves, I don't know, but hey IMO the users are in charge. I thought there were already loads of overlays, and it's also easy to add pkgs to sunrise. Moving of pkgs can also be done to clear out the unsupported pkgs.
The thing I found interesting, as a geek, was the idea of an automated process to move pkgs based on a flag, which could easily be based on a poll, or any other mechanism. I'm happy to work on such a system, but as to what policies it implements, that's up to the users, which could be treecleaners for unsupported pkgs, and could be gentoo users who want to keep hold of old ebuilds in an easily accessible overlay.
I'd guess we could have two new overlays, so-overlay for outdated pkgs like XMMS, and unsupported for ebuild-level support. Whether that's useful or not, I don't know, I'm perfectly happy with gentoo as it is |
|
| Back to top |
|
|
Conan
Guru
Joined: 02 Nov 2004
Posts: 360
|
| Posted: Sat Jan 06, 2007 5:12 pm Post subject: |
|
|
| Moving packages that only have ebuild level support into an overlay would be nixing a large % of the tree (no numbers, but I'd say at least half.) By doing this all users would just enable this "overlay" and we'd be at the same point. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 06, 2007 6:01 pm Post subject: |
|
|
| I see what you mean. I guess it'd be for stuff like the kernel pkgs then, if y'all think that's a good idea. |
|
| Back to top |
|
|
Conan
Guru
Joined: 02 Nov 2004
Posts: 360
|
| Posted: Sat Jan 06, 2007 6:14 pm Post subject: |
|
|
| The kernel stuff is no different. Its supported on an ebuild level. Half the tree is only supported on an ebuild level. You are trying to fix a problem that doesn't exist. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 06, 2007 6:20 pm Post subject: |
|
|
Mate, as I said, I'm perfectly happy with things as they are. It's not my idea, and TBH I agree with you:
| Quote: | | Why they can't just copy the ebuilds and keep adjusting the version numbers, or even heaven forbid, compile the source themselves, I don't know, but hey IMO the users are in charge. I thought there were already loads of overlays, and it's also easy to add pkgs to sunrise. |
As someone else said, what's wrong with a local overlay? |
|
| Back to top |
|
|
drwook
Veteran
Joined: 30 Mar 2005
Posts: 1324
Location: London
|
| Posted: Sat Jan 06, 2007 6:52 pm Post subject: |
|
|
| Conan wrote: | | Moving packages that only have ebuild level support into an overlay would be nixing a large % of the tree (no numbers, but I'd say at least half.) By doing this all users would just enable this "overlay" and we'd be at the same point. |
++ |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 06, 2007 7:23 pm Post subject: |
|
|
| One thing though- I thought people wanted the tree to be thinned out. If that's so, it makes sense to do this, and would also solve the op's initial problem in that only application-supported pkgs would be in the main tree. |
|
| Back to top |
|
|
drwook
Veteran
Joined: 30 Mar 2005
Posts: 1324
Location: London
|
| Posted: Sat Jan 06, 2007 7:49 pm Post subject: |
|
|
| steveL wrote: | | One thing though- I thought people wanted the tree to be thinned out. If that's so, it makes sense to do this, and would also solve the op's initial problem in that only application-supported pkgs would be in the main tree. |
Thinned out has advantages, but split in two halves that both still need to be maintained probably doesn't. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
