Re: how to package Haskell libraries
On Mon, Jun 23, 2003 at 10:38:40AM +0200, Marcelo E. Magallon wrote: > On Sun, Jun 22, 2003 at 09:07:05PM -0400, Colin Walters wrote: > > > Right, but that approach definitely has some disadvantages, namely > > fragility and the fact that we're kind of subverting the whole idea of > > binary packages. > > It kind of depends on what "Haskell library" means. Is it more like a C > library (potentially complex build system, dependencies, etc) or is it > more like a Perl module? I think the problem is that it could vary, and probably there needs to be at least support for binary haskell libraries. Certainly any library that is pure haskell probably will have a pretty simple build system. But a lot of interesting haskell "libraries" would involve bindings to other libraries, so installing them on the users' machine would require dev versions of those libraries, which would be annoying to an end user... on the other hand, as far as I know haskell doesn't support dynamic linking, which would mean that the library packages would themselves be -dev packages, and dependency (as opposed to just build-dependency) on -dev packages would be normal. On consideration, I think I'd vote for the "build binaries at install time" approach. The only problem with it is that it may take an awful lot of time to do so. But as long as haskell developers (or people compiling a haskell package from source) are the only ones to suffer from this wait, it seems like a good tradeoff. If we require a separate package for each compiler, I imagine many library packagers would opt for just packaging their library for ghc, which would be a shame as far as portability goes. -- David Roundy http://www.abridgegame.org
Re: Announcing Debian Package Tags
On Mon, Apr 28, 2003 at 09:46:47PM -0500, Manoj Srivastava wrote: > On Mon, 28 Apr 2003 17:06:14 -0400, David Roundy > <[EMAIL PROTECTED]> said: > > probably wouldn't hid mp3blaster. Maybe novices should only be > > shown gui programs after all. They probably don't want to be using > > a shell anyways... > > I would object to such a major disservice to people just > because they happen to be new to Linux. This is blatant > discrimination. I wasn't saying that novices shouldn't be using a shell. Just that I do think it would be helpful to allow novices, if they wish, to browse only those packages which don't require the use of a shell, which hardly seems discriminatory to me. -- David Roundy http://civet.berkeley.edu/droundy/
Re: Announcing Debian Package Tags
On Mon, Apr 28, 2003 at 03:35:17PM -0400, Colin Walters wrote:
> Hi David,
>
> On an unrelated tangent, let me say: darcs is cool :)
Thanks! :)
> On Mon, 2003-04-28 at 13:51, David Roundy wrote:
> > I would hope that rather than such generic terms, one could specify
> > more specific tags for highly specialized packages and have these tags
> > imply a certain degree of specialization. So this way a user
> > interested in a specific specialization would be able to browse
> >
> > specialized
> > bioinformatics
> > physics
> > mpb
> > mpb-mpi
> > chemistry
>
> Well...there are already "chemistry" and "biology" tags. I do agree
> that specialization::{high,low} or whatever isn't perfect, but having
> both say "chemistry" and "specialized::chemistry" seems worse.
>
> I guess it sort of depends too on how tags like "biology" will be used.
> If say someone wrote a nice easy to use educational GNOME/KDE program
> that provided an introduction to biology, it seems to me it should be
> tagged "biology", but shouldn't be tagged specialized::biology.
>
> What solution do you propose?
I meant to suggest not an additional specialized::chemistry tag, but that
any package having the chemistry tag would also automatically have the
specialized tag. The counterexample you gave is valid: a chemistry game
for preschoolers would be flagged for specialists only. Perhaps what I
would want would be more like a set of "field of endeavor" flags all of
which would indicate the field in which it would be used. So I imagine the
following "field of endeavor" flags for this example
education
chemistry
physics
biology
Then we might define as specialized any package which has at least one
field of endeavor (of course, some packages like text editors won't have
a field of endeavor), but doesn't contain education. Obviously, education
isn't likely to be the only exception, but if we define specialized in this
sort of a manner, I think it would make it easier to define other variants
on it (as long as packages have been correctly categorized in terms of
field of endeavor).
On the other hand, even within a field of endeavor there are highly
specialized packages (of which mpb is an excellent example, which most
physicists probably would not be interested in), so something more might be
needed. But I would guess that you could get by pretty well with just a
set of field of endeavor tags.
I should perhaps mention that I don't think "field of endeavor" is a good
name, certainly not to expose to the user, although it's the best I can
come up with off the top of my head.
> > Again, I would hope that a less general tagging of packages could be
> > achieved, with the user level inferred from more specific tags. For
> > example, it would be nice to have tags indicating the style of user
> > interface a package supports. I imagine something like
> >
> > userlevel::novice = !specialized && (interface::gui || interface::curses)
>
> Maybe. But your proposal above brings in almost all the packages.
> Basically anything that's not biology or physics or whatever. That's
> far from what I want. I mean, the difference for a novice user between
> rhythmbox and (to pick a random example) mp3blaster is pretty large, in
> my opinion.
>
> This isn't to bash mp3blaster; it has a different (more technical)
> audience.
H. That is one problem with trying to include curses apps (which I was
a little worried about, but didn't want to leave out aptitude).
I think a great tag to have (but perhaps cumbersome to add to so many
packages) would be a set of keybindings tags, which would try to indicate
the default keybindings (since that is what a novice is going to see). So
packages could advertise keybindings::vi or keybindings::emacs, which would
exclude them from novice level... Aaack. I just checked, and off the top
of my head, I would categorize aptitude as keybindings::vi (since it
supports j and k for up and down. Then if gnome and kde were to agree on
some standard keybindings (they may already--I don't use either, except for
galeon), then we could have something like keybindings::kdegnomelike... or
just keybindings::windows or something. But I'm thinking maybe this would
be way too complicated, and while it would drop oleo off the novice list
probably wouldn't hid mp3blaster. Maybe novices should only be shown gui
programs after all. They probably don't want to be using a shell
anyways...
> I understand that goal. I hope my argument above is persuasive enough
> to convince you that something like userlevel:: is a good idea.
Well, I'm certainly convince
Re: Announcing Debian Package Tags
On Mon, Apr 28, 2003 at 12:30:54PM -0400, Colin Walters wrote: > Further, I'd like to add a new tag to the vocabulary for use with Debian > Desktop; this tag would reflect the overall "specialization" of the > package. A lot of packages in Debian are highly specialized, > interesting only to a relatively small percentage of our users; the > bioinformatics stuff is a good example. So I am thinking of something > like this: > > specialization::high > specialization::medium > specialization::low I would hope that rather than such generic terms, one could specify more specific tags for highly specialized packages and have these tags imply a certain degree of specialization. So this way a user interested in a specific specialization would be able to browse specialized bioinformatics physics mpb mpb-mpi chemistry I think this should work, since any specialized package must be specific to some field (or fields). So mpb (which I use) might show up under physics and engineering. > Basically I would want the Debian Desktop distribution to mainly include > "general-appeal" sort of software. Also, a tag to reflect the expected > user experience level for a piece of software might be be nice. This > overlaps a little with the specialization. Say: > > userlevel::novice > userlevel::expert Again, I would hope that a less general tagging of packages could be achieved, with the user level inferred from more specific tags. For example, it would be nice to have tags indicating the style of user interface a package supports. I imagine something like userlevel::novice = !specialized && (interface::gui || interface::curses) where you'd probably want to include other tags that I haven't thought of. The only practical way I could see defining the userlevel of packages would be in terms of such a definition anyways, and this would make it easier to customize the definitions for meta-distributions (e.g. maybe you wouldn't consider any text interface to be novice-friendly--although this would make you leave out aptitude, which seems like a bad idea--on the other hand for a novice with noone handy to help them out, even aptitude would be confusing). I guess what I'm getting at is that I think that the tags should be as simple and obvious as possible, leaving more subtle distinctions as derived tags wherever possible. The tags that are applied directly should be as obvious as possible, so that when reading the tag description anyone familiar with a given package will always give the same answer. Of course, this is the job of the tag task force, so maybe I should leave it up to them... -- David Roundy http://civet.berkeley.edu/droundy/
Re: Description to man pages
On Wed, Apr 03, 2002 at 10:45:29PM +0200, Otto Wyss wrote: > Since I hated to start dselect again and again just to read a package > description I wrote a script "dsc2man" which creates appropriate man > pages for each package. Wouldn't it be easier to just use apt-cache show ? -- David Roundy http://civet.berkeley.edu/droundy/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
