Re: suggestions for ports screening
Anton Berezin wrote: On Sun, Nov 11, 2007 at 04:59:58PM +1100, Edwin Groothuis wrote: On Sat, Nov 10, 2007 at 10:36:45PM -0500, Chuck Robey wrote: An example? If a programmer asks you if you want the blotz program (I make up great fake names, don't I?) hows the user going to know the the blotz program is a particular sound program, when they have no sound card? When I search for a certain program with some capabilities, I go through the INDEX file (/usr/ports/INDEX) or I go to freshmeat or freshports and do a search there. If I don't see "blotz" there, I'm not interested in it. OK, My suggestion is for a two level system (yes, some of you are going to recognize some of this from other OSes. G'wan, brag about it). The first part is a small list of keywords (well, not terribly small, maybe 100-200 of them, but most user's personal lists would be far shorter). These words are descriptive of the sort of machine environment the user wants, like, they might have the words SOUND, FMRADIO and TELEVISION to show that they care to have those sort of dependencies built. All ports would be required to export a list of words that they check for, before they build. If a browser sees no SOUND word, it requires to sound dependencies be built. Let me repeat this to get it clearly: the words are used to qualify the dependcency lists, but if a particular port is chosen, then it gets built, period. If a user asks for that sound program explicitly, then it gets built, SOUND word or no SOUND word. It's the dependency lists that have to check and modify themselves. This sounds like the ports-tag project started by tobez@ a long time ago: http://www.tobez.org/port-tags/. Not sure what the current status is. It's not being developed any further due to general lack of interest. I would love to have it resurrected provided there is aforementioned interest. OK. I got very little truly negatives, and 2 semi-positives, so I will start to gen up the software. Understand (as I sure do) that just because I begin to write it is absolutely no indication that my software will be accepted. Lots of reasons why it still might get stopped, or maybe someone else might write a better one (it's possible, I guess, that maybe I'm NOT the finest programmer in the known universe), so if you are really against it, go ahead and speak up anytime you feel like it, your chances to veto things hasn't gone away. I'll write up the software, probably change maybe 10 ports to allow it also. The only thing I would change if I could would be, I'd REALLY like to have Python available as a language available for system work, but as it stands now, I don't see Python as being a candidate for inclusion in usr.bin. Love to see that (or even Ruby) but that's a fight for another day. One I figure I'd probably lose. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for ports screening
[LoN]Kamikaze wrote:
Chuck Robey wrote:
...
This might either turn into a bikeshed or a creative brainstorming. I hope for
the latter, so I take part.
Yeah, if it looked like a flamebait, I would run for the hills myself,
but it looks pretty good so far.
My rule of thumb is to stick to the defaults if I don't know what I'm doing. I
think that could be put mentioned in the handbook, just to make beginners feel
more confident about what they're doing.
Problem is, those defaults take absolutely no notice whatever of a
user's local environment. It does allow some level of user input, but
since the way things have been implemented has been totally up to the
programmer, our system right now is very nearly out of control, as far
as an unbelieveable level of grabiness for dependencies. The other day,
I selected one single port, and when portmanager had completed, ~200
more things had ben installed. I'm just saying that we need some system
that pushes people to do a bit more active screening.
You have also to recognize, it's largely a human, psychological thing
I'm am trying to manipulate, because our present system if implemented
100% perfectly, would absolutely do the job. It's the particular human
emphasis'es (how do you pluralize emphasis?) that I want to play with.
An example? If a programmer asks you if you want the blotz program (I
make up great fake names, don't I?) hows the user going to know the the
blotz program is a particular sound program, when they have no sound card?
OK, My suggestion is for a two level system (yes, some of you are going
to recognize some of this from other OSes. G'wan, brag about it). The
first part is a small list of keywords (well, not terribly small, maybe
100-200 of them, but most user's personal lists would be far shorter).
These words are descriptive of the sort of machine environment the user
wants, like, they might have the words SOUND, FMRADIO and TELEVISION to
show that they care to have those sort of dependencies built. All ports
would be required to export a list of words that they check for, before
they build. If a browser sees no SOUND word, it requires to sound
dependencies be built.
I like the sound of that. It might be a bigger change that would have to be
implemented into ports over a long period of time. And of course it would only
appear in ports where maintainer are willing to spend the time to support it.
These dependencies can show up on the list in the form of KEYWORD=VALUE,
where value can be used to point towards a user's preference. A user
might set BROWSER=www/seamonkey,www/mozilla in the list, so this gives a
port all the info it would need to match dependencies nicely, without
having to get interactive about it.
How would you deal with cases in which following the users wishes is not
supported. What if a user has SOUND=direct defined to tell programs to use
/dev/dsp instead of a sound server like arts or estd? Most KDE applications
only work with arts, no matter how much you wish otherwise.
OK, this is only the first part ... the second part is a list of the
names of ports. This REJECT list serves as a rejection filter: if a
port finds it's way upon that list, it can't get put on any dependency
list at all. I, personally, never like any Samba ports, so I could
stick all the Samba ports on the REJECT list, or I could just fail to
put SAMBA as a keyword. My choice, although if I stuck a particular set
of ports on that list, I'd have to watch new ports, so new Samba port
didn't sneak past me. Still, it would allow a user to really have all
the control anyone could ask for. or they could ignore it and still not
face disaster as long as they maintained the KEYWORD list.
That's kinda possible already.
Like I said above, yes, our current system CAN DO the job, but with the
way that it's pointed, psycolgically, it's doing a particularly poor job
of it. We need a change that pushes the level of control,
psychologically, more towards the user. I cannot, do not argue that our
present system can't do the job, I am saying that it isn't doing it.
.if ${.CURDIR:M*/ports/*samba*}
IGNORE= I don't like samba!
.endif
Are you seriously asking all of are tech aznd non-tech users to keep
track of all the names of any ports that supply a particular
functionality set (do you really think that all Samba ports have the
name Samba? That's silly) BUT if you required programmers to set the
correct list of KEYWORDS, then that's a much more obvious and easy to
check item.
This would keep everything with samba in the name from being built. I don't
know how the depending ports would react to that, though.
I guess, from all the guesses that came in., I maybe better admit where
I stole this idea... Gentoo's Portage system no other. I DO NOT propose
to bring that system in, I really like FreeBSD system, based upon our
make(7). But, I do propose to bring in sections of their USE system,
for qualifying
Re: suggestions for ports screening
On Sun, Nov 11, 2007 at 04:59:58PM +1100, Edwin Groothuis wrote: > On Sat, Nov 10, 2007 at 10:36:45PM -0500, Chuck Robey wrote: > > An example? If a programmer asks you if you want the blotz program (I > > make up great fake names, don't I?) hows the user going to know the the > > blotz program is a particular sound program, when they have no sound card? > > When I search for a certain program with some capabilities, I go > through the INDEX file (/usr/ports/INDEX) or I go to freshmeat or > freshports and do a search there. If I don't see "blotz" there, I'm > not interested in it. > > > OK, My suggestion is for a two level system (yes, some of you are going > > to recognize some of this from other OSes. G'wan, brag about it). The > > first part is a small list of keywords (well, not terribly small, maybe > > 100-200 of them, but most user's personal lists would be far shorter). > > These words are descriptive of the sort of machine environment the user > > wants, like, they might have the words SOUND, FMRADIO and TELEVISION to > > show that they care to have those sort of dependencies built. All ports > > would be required to export a list of words that they check for, before > > they build. If a browser sees no SOUND word, it requires to sound > > dependencies be built. Let me repeat this to get it clearly: the words > > are used to qualify the dependcency lists, but if a particular port is > > chosen, then it gets built, period. If a user asks for that sound > > program explicitly, then it gets built, SOUND word or no SOUND word. > > It's the dependency lists that have to check and modify themselves. > > This sounds like the ports-tag project started by tobez@ a long > time ago: http://www.tobez.org/port-tags/. Not sure what the current > status is. It's not being developed any further due to general lack of interest. I would love to have it resurrected provided there is aforementioned interest. :-) Cheers, \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for ports screening
This whole thing you've described looks pretty similar to one of debian's package managements feature. Every package can set a "Provides:" directive, and specify what kind of thing does it provide. Like apache, nginx, lighttpd, and so on provide a "httpd". Whenever an application needs such a service it depends on "httpd". After this, the package management picks one of the available ones. It would also be good to take a look at this, it's in use for many years by now, and stands its ground. Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise. pgpbq4Qh8pOrO.pgp Description: PGP signature
Re: suggestions for ports screening
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Edwin Groothuis wrote: > On Sat, Nov 10, 2007 at 10:36:45PM -0500, Chuck Robey wrote: >> An example? If a programmer asks you if you want the blotz program (I >> make up great fake names, don't I?) hows the user going to know the the >> blotz program is a particular sound program, when they have no sound card? > > When I search for a certain program with some capabilities, I go > through the INDEX file (/usr/ports/INDEX) or I go to freshmeat or > freshports and do a search there. If I don't see "blotz" there, I'm > not interested in it. > >> OK, My suggestion is for a two level system (yes, some of you are going >> to recognize some of this from other OSes. G'wan, brag about it). The >> first part is a small list of keywords (well, not terribly small, maybe >> 100-200 of them, but most user's personal lists would be far shorter). >> These words are descriptive of the sort of machine environment the user >> wants, like, they might have the words SOUND, FMRADIO and TELEVISION to >> show that they care to have those sort of dependencies built. All ports >> would be required to export a list of words that they check for, before >> they build. If a browser sees no SOUND word, it requires to sound >> dependencies be built. Let me repeat this to get it clearly: the words >> are used to qualify the dependcency lists, but if a particular port is >> chosen, then it gets built, period. If a user asks for that sound >> program explicitly, then it gets built, SOUND word or no SOUND word. >> It's the dependency lists that have to check and modify themselves. > > This sounds like the ports-tag project started by tobez@ a long > time ago: http://www.tobez.org/port-tags/. Not sure what the current > status is. It's the Gentoo package masking system[*]. FreeBSD's KNOBS system sits in much the same territory. The big difference is that if I put 'WITHOUT_X11 = yes' in my /etc/make.conf on FreeBSD then I'll get a version of eg. emacs that doesn't depend on X11 but any other port that has non-optional dependencies on X11 will cause all that X11 stuff to be installed with never a murmur. Adding '-X11' (or whatever the precise syntax is) to the appropriate thing in /etc/make.conf on a Gentoo box will cause the portage system to block, or at least complain volubly about) the installation of X11 and anything that has an obligatory dependency on it. Personally I feel that the existing FreeBSD setup is counter- intuitive. If I don't want X11 on this server, then I just put 'WITHOUT_X11 = yes' in /etc/make.conf and ... oh. Enforcing the action of KNOBS at a global level would accord with POLA, and it shouldn't be impossibly difficult to insert into the existing state of things. Given that Gentoo blatantly stole the whole Portage concept from our ports[**], I feel that it would only be equitable if we returned the favour. Cheers, Matthew [*] Do I get a lollipop? [**] As they were perfectly entitled to do. - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNr8R8Mjk52CukIwRCKEXAJ0XH49mp6Zpnol77zLVhtxOmCuviACdEk2w qivLCOUNkLJetpl+LEgvElM= =DdaX -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for ports screening
Chuck Robey wrote:
> ...
This might either turn into a bikeshed or a creative brainstorming. I hope for
the latter, so I take part.
> Anyhow, here's the suggestion. The system we have, currently, is
> basically dependent on people who write ports instrumenting options to
> include or not include various options. A very large portion of those
> options are written up in such a way as to make it nearly impossible for
> a non-expert to figure out if a particular option is good for their use
> of not.
My rule of thumb is to stick to the defaults if I don't know what I'm doing. I
think that could be put mentioned in the handbook, just to make beginners feel
more confident about what they're doing.
> An example? If a programmer asks you if you want the blotz program (I
> make up great fake names, don't I?) hows the user going to know the the
> blotz program is a particular sound program, when they have no sound card?
That problem really exists, though.
> There are ways to fix this, you know. Read on.
>
> OK, My suggestion is for a two level system (yes, some of you are going
> to recognize some of this from other OSes. G'wan, brag about it). The
> first part is a small list of keywords (well, not terribly small, maybe
> 100-200 of them, but most user's personal lists would be far shorter).
> These words are descriptive of the sort of machine environment the user
> wants, like, they might have the words SOUND, FMRADIO and TELEVISION to
> show that they care to have those sort of dependencies built. All ports
> would be required to export a list of words that they check for, before
> they build. If a browser sees no SOUND word, it requires to sound
> dependencies be built.
I like the sound of that. It might be a bigger change that would have to be
implemented into ports over a long period of time. And of course it would only
appear in ports where maintainer are willing to spend the time to support it.
> These dependencies can show up on the list in the form of KEYWORD=VALUE,
> where value can be used to point towards a user's preference. A user
> might set BROWSER=www/seamonkey,www/mozilla in the list, so this gives a
> port all the info it would need to match dependencies nicely, without
> having to get interactive about it.
How would you deal with cases in which following the users wishes is not
supported. What if a user has SOUND=direct defined to tell programs to use
/dev/dsp instead of a sound server like arts or estd? Most KDE applications
only work with arts, no matter how much you wish otherwise.
> OK, this is only the first part ... the second part is a list of the
> names of ports. This REJECT list serves as a rejection filter: if a
> port finds it's way upon that list, it can't get put on any dependency
> list at all. I, personally, never like any Samba ports, so I could
> stick all the Samba ports on the REJECT list, or I could just fail to
> put SAMBA as a keyword. My choice, although if I stuck a particular set
> of ports on that list, I'd have to watch new ports, so new Samba port
> didn't sneak past me. Still, it would allow a user to really have all
> the control anyone could ask for. or they could ignore it and still not
> face disaster as long as they maintained the KEYWORD list.
That's kinda possible already.
.if ${.CURDIR:M*/ports/*samba*}
IGNORE= I don't like samba!
.endif
This would keep everything with samba in the name from being built. I don't
know how the depending ports would react to that, though.
> 3 stale to the first programmer who notices where I stole the idea from,
> and a used mousetrap to him (or her?) who knows the correct name of the
> KEYWORD list. If you hate the idea, just say so, believe me I will be
> catching all responses, and I will report your overwhelming acceptance
> or rejection, as the case may be. It shouldn't take a master's degree
> to guess my own opinion.
I came over from an OS without a package system (Windows), so I've got no idea
where you took all that from.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for ports screening
On Sat, Nov 10, 2007 at 10:36:45PM -0500, Chuck Robey wrote: > An example? If a programmer asks you if you want the blotz program (I > make up great fake names, don't I?) hows the user going to know the the > blotz program is a particular sound program, when they have no sound card? When I search for a certain program with some capabilities, I go through the INDEX file (/usr/ports/INDEX) or I go to freshmeat or freshports and do a search there. If I don't see "blotz" there, I'm not interested in it. > OK, My suggestion is for a two level system (yes, some of you are going > to recognize some of this from other OSes. G'wan, brag about it). The > first part is a small list of keywords (well, not terribly small, maybe > 100-200 of them, but most user's personal lists would be far shorter). > These words are descriptive of the sort of machine environment the user > wants, like, they might have the words SOUND, FMRADIO and TELEVISION to > show that they care to have those sort of dependencies built. All ports > would be required to export a list of words that they check for, before > they build. If a browser sees no SOUND word, it requires to sound > dependencies be built. Let me repeat this to get it clearly: the words > are used to qualify the dependcency lists, but if a particular port is > chosen, then it gets built, period. If a user asks for that sound > program explicitly, then it gets built, SOUND word or no SOUND word. > It's the dependency lists that have to check and modify themselves. This sounds like the ports-tag project started by tobez@ a long time ago: http://www.tobez.org/port-tags/. Not sure what the current status is. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
suggestions for ports screening
May as well get all my bright ideas out and over with, all at once. You see, I've spent the last few years exploring other OSes, and finally decided I was right, way bakc when I was running FreeBSD to begin with. BUT I have to admit that I saw several good ideas while I was out and about. I have never seen a better package system (at least, in my own opinion, you understand) than FreeBSD ports, BUT the methodology for qualifying dependencies isn't as good as some I've seen, so I wanted to open a discussion about this. If, at the end of this, no one agrees, all I ever ask is that folks give a listen, NOT that anyone actually agrees, so I will happily fold up my tent and slink away. Anyhow, here's the suggestion. The system we have, currently, is basically dependent on people who write ports instrumenting options to include or not include various options. A very large portion of those options are written up in such a way as to make it nearly impossible for a non-expert to figure out if a particular option is good for their use of not. An example? If a programmer asks you if you want the blotz program (I make up great fake names, don't I?) hows the user going to know the the blotz program is a particular sound program, when they have no sound card? There are ways to fix this, you know. Read on. OK, My suggestion is for a two level system (yes, some of you are going to recognize some of this from other OSes. G'wan, brag about it). The first part is a small list of keywords (well, not terribly small, maybe 100-200 of them, but most user's personal lists would be far shorter). These words are descriptive of the sort of machine environment the user wants, like, they might have the words SOUND, FMRADIO and TELEVISION to show that they care to have those sort of dependencies built. All ports would be required to export a list of words that they check for, before they build. If a browser sees no SOUND word, it requires to sound dependencies be built. Let me repeat this to get it clearly: the words are used to qualify the dependcency lists, but if a particular port is chosen, then it gets built, period. If a user asks for that sound program explicitly, then it gets built, SOUND word or no SOUND word. It's the dependency lists that have to check and modify themselves. These dependencies can show up on the list in the form of KEYWORD=VALUE, where value can be used to point towards a user's preference. A user might set BROWSER=www/seamonkey,www/mozilla in the list, so this gives a port all the info it would need to match dependencies nicely, without having to get interactive about it. OK, this is only the first part ... the second part is a list of the names of ports. This REJECT list serves as a rejection filter: if a port finds it's way upon that list, it can't get put on any dependency list at all. I, personally, never like any Samba ports, so I could stick all the Samba ports on the REJECT list, or I could just fail to put SAMBA as a keyword. My choice, although if I stuck a particular set of ports on that list, I'd have to watch new ports, so new Samba port didn't sneak past me. Still, it would allow a user to really have all the control anyone could ask for. or they could ignore it and still not face disaster as long as they maintained the KEYWORD list. 3 stale to the first programmer who notices where I stole the idea from, and a used mousetrap to him (or her?) who knows the correct name of the KEYWORD list. If you hate the idea, just say so, believe me I will be catching all responses, and I will report your overwhelming acceptance or rejection, as the case may be. It shouldn't take a master's degree to guess my own opinion. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
