[clc-devel] contrib/opt merge: second thoughts
Hi, Lately, I'm having second thoughts whether it's a good idea to merge opt and contrib into one collection. Not to be missunderstood, I consider it very important to merge CVS repositories, and CRUX/CLC. But somehow I don't like the idea of having 5 window managers, MTA's, web servers and the like in opt. I've been discussing this with Juergen quickly, and he seemed to agree to that consideration. My suggestion would be to keep a separate category, maybe called 'extra' or something like that, and allow maintainers to suggest ports for addition into opt. Those contrib ports which are currently included on the ISO would certainly make good candidates for that. In the end, we have a need for this distinction anyway, since we couldn't include 'opt' completely an ISO if it was merged with contrib. At CRUXCon 2004, we said we'd introduce a 'core group', marked with an attribute in the Pkgfile. To me, keeping a third collection seems very similar, but easier to understand for users. We'd then have the following hierarchy: - base: ports required to run a crux system - opt: ports required depending on the use of the machine - extra: ports which replace ports from opt (function wise) or extend it - contrib: user contributed ports Bad idea, good idea? Kind regard, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Johannes Winkelmann <jw@tks6.net> [2005-05-26 13:46]:
to that consideration. My suggestion would be to keep a separate category, maybe called 'extra' or something like that, and allow maintainers to suggest ports for addition into opt. Those contrib ports which are currently included on the ISO would certainly make good candidates for that.
[...]
We'd then have the following hierarchy: - base: ports required to run a crux system - opt: ports required depending on the use of the machine - extra: ports which replace ports from opt (function wise) or extend it
- contrib: user contributed ports
Not sure I understood that correctly. You're suggesting that we'd kinda rename contrib to 'extra' in the first step, and then move some important/very useful ports to opt? If I got that right, it sounds like a good idea to me. Regards, Tilman -- learn to quote: http://www.netmeister.org/news/learn2quote.html
Hi Tilman, On Thu, May 26, 2005 at 15:39:44 +0200, Tilman Sauerbeck wrote: [...]
Not sure I understood that correctly. You're suggesting that we'd kinda rename contrib to 'extra' in the first step, and then move some important/very useful ports to opt? That sums it up really well, yes :-).
Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Do you think we could have sub directories underneath opt? like /opt/x11-win or /opt/irc etc? -J On May 26, 2005, at 11:08 AM, Johannes Winkelmann wrote:
Hi Tilman,
On Thu, May 26, 2005 at 15:39:44 +0200, Tilman Sauerbeck wrote: [...]
Not sure I understood that correctly. You're suggesting that we'd kinda rename contrib to 'extra' in the first step, and then move some important/very useful ports to opt? That sums it up really well, yes :-).
Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net _______________________________________________ clc-devel mailing list clc-devel@lists.berlios.de http://lists.berlios.de/mailman/listinfo/clc-devel
Hi there I myself experienced categorizing ports as rather annoying. The only difference it made was having to search in which subdirectory the port was located. Well, well, maybe there are also pros which i dont know of ;) Let me know! Regards, stephan Jonathan Asghar wrote:
Do you think we could have sub directories underneath opt? like /opt/x11-win or /opt/irc etc?
-J
On May 26, 2005, at 11:08 AM, Johannes Winkelmann wrote:
Hi Tilman,
On Thu, May 26, 2005 at 15:39:44 +0200, Tilman Sauerbeck wrote: [...]
Not sure I understood that correctly. You're suggesting that we'd kinda rename contrib to 'extra' in the first step, and then move some important/very useful ports to opt?
That sums it up really well, yes :-).
Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net _______________________________________________ clc-devel mailing list clc-devel@lists.berlios.de http://lists.berlios.de/mailman/listinfo/clc-devel
_______________________________________________ clc-devel mailing list clc-devel@lists.berlios.de http://lists.berlios.de/mailman/listinfo/clc-devel
True, it would be tedious but it could make life easier. There is so much software out there that it would be kinda nice to categorize it in my opinion. Keep it simple true, but sometimes some organization can help. Thoughts? -J On May 26, 2005, at 12:05 PM, Stephan Seidt wrote:
Hi there
I myself experienced categorizing ports as rather annoying. The only difference it made was having to search in which subdirectory the port was located. Well, well, maybe there are also pros which i dont know of ;) Let me know!
Regards, stephan
Jonathan Asghar wrote:
Do you think we could have sub directories underneath opt? like /opt/x11-win or /opt/irc etc? -J On May 26, 2005, at 11:08 AM, Johannes Winkelmann wrote:
Hi Tilman,
On Thu, May 26, 2005 at 15:39:44 +0200, Tilman Sauerbeck wrote: [...]
Not sure I understood that correctly. You're suggesting that we'd kinda rename contrib to 'extra' in the first step, and then move some important/very useful ports to opt?
That sums it up really well, yes :-).
Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net _______________________________________________ clc-devel mailing list clc-devel@lists.berlios.de http://lists.berlios.de/mailman/listinfo/clc-devel
clc-devel mailing list clc-devel@lists.berlios.de http://lists.berlios.de/mailman/listinfo/clc-devel
Hi, On Thu, May 26, 2005 at 11:26:54 -0500, Jonathan Asghar wrote:
Do you think we could have sub directories underneath opt? like /opt/x11-win or /opt/irc etc?
Another one that comes up from time to time Per's main argument here: http://marc.theaimsgroup.com/?l=crux&m=107592763603892&w=2 There has been some talk about introducing 1:n package-category relationships by making active use of the 'group'/'category' tag in Pkgfiles: http://marc.theaimsgroup.com/?l=crux&m=107599052116162&w=2 but I think there was no work done on this. Finally, it's very hard to get the granularity right: too many categories will give the packagers a lot of work when categorizing a package (which often means that it's not done properly), and too few will give you again a superset of what you were looking for. In the end, proper package descriptions and tools to search packages by description are a pretty good alternative to categories (IMHO, of course). Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
I understand now. Sorry to bring out the dead horse and beat it. ;) -J Johannes Winkelmann wrote:
Hi,
On Thu, May 26, 2005 at 11:26:54 -0500, Jonathan Asghar wrote:
Do you think we could have sub directories underneath opt? like /opt/x11-win or /opt/irc etc?
Another one that comes up from time to time Per's main argument here: http://marc.theaimsgroup.com/?l=crux&m=107592763603892&w=2
There has been some talk about introducing 1:n package-category relationships by making active use of the 'group'/'category' tag in Pkgfiles: http://marc.theaimsgroup.com/?l=crux&m=107599052116162&w=2 but I think there was no work done on this.
Finally, it's very hard to get the granularity right: too many categories will give the packagers a lot of work when categorizing a package (which often means that it's not done properly), and too few will give you again a superset of what you were looking for. In the end, proper package descriptions and tools to search packages by description are a pretty good alternative to categories (IMHO, of course).
Regards, Johannes
On May 26, 2005 5:46, Johannes Winkelmann wrote:
Hi,
Lately, I'm having second thoughts whether it's a good idea to merge opt and contrib into one collection. Not to be missunderstood, I consider it very important to merge CVS repositories, and CRUX/CLC. But somehow I don't like the idea of having 5 window managers, MTA's, web servers and the like in opt.
Why not merge opt and contrib, and then "sticky tag" all the opt ports as OPT? We already have a CLC tag, so perhaps this tag-distinction could be leveraged to our advantage?
I've been discussing this with Juergen quickly, and he seemed to agree to that consideration. My suggestion would be to keep a separate category, maybe called 'extra' or something like that, and allow maintainers to suggest ports for addition into opt. Those contrib ports which are currently included on the ISO would certainly make good candidates for that.
I like this idea. Could it be implemented with a persistent tag? To suggest a port for inclusion into OPT, tag it EXTRA, and if one feels that it might require a reason, send an email to Per as well. File.cvsup would split up the large CVS collection into the usual, comfortable collection of directories that make up /usr/ports. Then there no Pkgfile changes are needed. Wouldn't the 'core group' necessitate some kind of parsing function complexity?
We'd then have the following hierarchy: - base: ports required to run a crux system - opt: ports required depending on the use of the machine - extra: ports which replace ports from opt (function wise) or extend it
- contrib: user contributed ports
Ok, so base would remain base. Opt would be a tag. Extra would a tag. CLC is already a tag. Perhaps CLC should go in /usr/ports/clc? Contrib would be user-contributed ports. (this sounds like that "people" collection of a little while ago) So: / / BASE: Per Our CVS / / \ Many ports / OPT:Per EXTRA: Us One root \ \ / Tagged for Sanity. \ CLC: Us \ | \ CONTRIB: Users Will "CONTRIB: Users" and "CLC: Us" be merged in CVS, or in /usr/ports/contrib? What will happen to the CONTRIB-X_Y tag? Will the user's contrib automatically be tagged CONTRIB-X_Y (CURRENT)? Finally, what belongs where? For example, where should I put a very nice QT3 style/theme, or a not-everyone-will-use-this application? (ed2k-gtk-gui, or gnugo, for example) Should it remain in my httpup repo, should it be synced into "CONTRIB: Users"? Does the "persistent tags single CVS split into multiple dirs via cvsup" idea sound simple and manageable enough? Jonathan Asghar mentioned splitting up ports according to function. It seems like we can probably last another year without this, but perhaps it might be a good idea for CRUX-3.0, if our "CONTRIB: Users" grows significantly? Jay: Do you think this functionality could be implemented the .sync file? The .sync would be a "sync to where" token. Just trying to think about how to keep things simple, in an increasingly complex climate. Nick P.S. I'm not sure if I understand the mechanics of a "sticky tag". It sounds like it would be useful as a persistent marker...
Johannes Winkelmann wrote:
Hi,
Lately, I'm having second thoughts whether it's a good idea to merge opt and contrib into one collection. Not to be missunderstood, I consider it very important to merge CVS repositories, and CRUX/CLC. But somehow I don't like the idea of having 5 window managers, MTA's, web servers and the like in opt.
I've been discussing this with Juergen quickly, and he seemed to agree to that consideration. My suggestion would be to keep a separate category, maybe called 'extra' or something like that, and allow maintainers to suggest ports for addition into opt. Those contrib ports which are currently included on the ISO would certainly make good candidates for that. In the end, we have a need for this distinction anyway, since we couldn't include 'opt' completely an ISO if it was merged with contrib. At CRUXCon 2004, we said we'd introduce a 'core group', marked with an attribute in the Pkgfile. To me, keeping a third collection seems very similar, but easier to understand for users.
We'd then have the following hierarchy: - base: ports required to run a crux system - opt: ports required depending on the use of the machine - extra: ports which replace ports from opt (function wise) or extend it
- contrib: user contributed ports
I agree with jdolan. I don't see a big issue in merging them since per already includes some contrib ports in ISO without including the whole ISO. I think the problem might be in some "core" dependencies: like openssl or openssh or xorg. But I think a good solution would be to move those to base. have base sort of be a default functioning system, but move all optional stuff: gtk group, etc.. etc.. to contrib. If that's not convenient, then why have extra in addition to opt? why not just keep opt the way it is? what's wrong with having "extra" ports on contrib the way it is now? Victor
On Thu, 26 May 2005 13:46:26 +0200 Johannes Winkelmann wrote:
But somehow I don't like the idea of having 5 window managers, MTA's, web servers and the like in opt.
That is something I would not care about :-)
- base: ports required to run a crux system - opt: ports required depending on the use of the machine - extra: ports which replace ports from opt (function wise) or extend it
- contrib: user contributed ports
Sounds fast & easy to implement. Only one point that is important for me: I'd like to see CRUX(CLC?) and user contributed ports separated from each other. I don't trust every CRUX user and I'm a bit afraid about malicious ports. You know, especially as prt-get(8) user you are at risk... let's face it, how often do you look into a Pkgfile *before* you run 'prt-get install xzy'? bye, danm -- Daniel Mueller http://www.danm.de Berlin, Germany OpenPGP: 1024D/E4F4383A
On 05/26/05 13:46 Johannes Winkelmann wrote:
Hi,
Hi, sorry for joining the discussion a bit late,
Lately, I'm having second thoughts whether it's a good idea to merge opt and contrib into one collection. Not to be missunderstood, I consider it very important to merge CVS repositories, and CRUX/CLC. But somehow I don't like the idea of having 5 window managers, MTA's, web servers and the like in opt. [cut: introduction of the "extra" collection]
For the sake of simplicity I slightly prefer merging the current contrib with the opt collection, without adding an extra collection. This way we can maintain the current purpose of the collections, adjusted for the new contrib: - base: don't go out without this - opt: you almost certainly need some of these, and they're well maintained - contrib: 3rd party, handle with care Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
participants (8)
-
Daniel Mueller -
Johannes Winkelmann -
Jonathan Asghar -
Nick Steeves -
Simone Rota -
Stephan Seidt -
Tilman Sauerbeck -
Victor