Re: [gentoo-portage-dev] coveted features

Re: [gentoo-portage-dev] coveted features

[Daniel Robbins]

On Sat, 2003-12-27 at 08:31, Bart Lauwers wrote:
> 10. ability for a package install to trigger a USE flag(, like evms2 for 
> instance)

This has been supported for quite some time in the current version of
Portage. Auto-USE settings are defined in
/etc/make.profile/use.defaults. If the package on the right is
installed, the USE variable on the left is automatically enabled.

This feature is on by default in Portage. It can be turned on or
off by overriding the USE_ORDER variable defined in /etc/make.globals.
The current default setting of "env:conf:auto:defaults" tells Portage
to use the following information to determine USE:

1) first, get USE information from make.defaults
2) then, consult use.defaults and enable any USE vars based on what
packages are installed.
3) then, consult /etc/make.conf and apply the settings ("-foo bar") to
the USE settings so far.
4) then, consult USE in the current environment (environment variable)
and apply the settings ("-cow moo") to the use settings so far.

This results in the current USE settings. I do think that not too many
people know about auto-USE, so it is somewhat under-utilized.

> 12.  Package names are too inflexible for version numbers. It is clear the
> assumptions in portage do not match or allow for all naming schemes vendors
> might have. There needs to be a simple way to identify vendor releases so that
> it is clear from a portage search which actual version the user will be
> installing of the package. 

Having a somewhat rigid versioning scheme can actually be a good thing,
as Portage needs to be able to determine if a particular version of a
package is "newer" than another. If we support all possible versioning
schemes, it will be hard to determine if some version strings are newer
than others. So we need to have some kind of standard versioning.
Otherwise, how do you tell if "foo-1a" is newer, older or the same as
"foo-a1," etc.

As long as this requirement is kept in mind, we can look at ways at
expanding the version syntax.

> 13. Add a tripwire / md5 or crc feature to portage so it can check the entire 
> system for consistency with it's database and report discrepancies.

This will be added to our requirements doc.

> 15. Better design for supporting many architectures and OS targets (why not 
> have a portage for cygwin? or one for Solaris?)

Will be supported from the beginning.

> 16. separation of all user interface and functional components so that 
> graphical installers can be built/adjusted easily on top of portage.

Will be done from the start.

> 17. ACCEPT_LICENSE="..."

We will have a generic masking model that will allow masking decisions
to be made based on any part of metadata. So this will be supported out
of the box.

> 21. ability for portage to back up any file overwritten so an undo option can 
> be created (allowing one to backtrack to past states)

I will be making sure this gets added.

> 22. support for xdelta or the likes on source files, we download way more then 
> we should for keeping a system up to date

We will have a plugin or component model for fetching files, which will
allow a plugin or component to be written to do this. We'll keep thing
sufficiently abstract so that this is possible.

> 23. run checks only on uncompressed files so users can recompress archives at 
> their leasure in different formats if desired. (so source urls should 
> probably not include an extension for compression or know how to verify for 
> recompressed sources in other formats before downloading)

I think this would be a good design goal.

Haven't ignored your other requests, just commenting on a handful atm :)

Regards,

Daniel


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] coveted features

[Bart Lauwers]

All the more reason to build the docs from the code directly with doxygen or 
whatever. I'm pretty sure nobody writes code with the intent it doesn't get 
used, from a coder standpoint having documentation helps feature acceptance.

This feature probably is documented but since I can't find that documentation 
quickly (i.e. just could find it in under 5 minutes) it might as well not 
exist to the majority of devs. We s'port too many hidden feats.

Anyway we've got lots of docs but were lacking a good taxonomy for them, do we 
have any librarians helping the docs team? (cc'ing doc to get a reply about 
this)

So let me rephrase that portage docs need to be complete and up to date at all 
times (at least an english version, devs should know enough english). Linking 
the documentation to the code is the only way I can see this happen.

 Bart.

On Monday 29 December 2003 00:02, Daniel Robbins wrote:
>
> This results in the current USE settings. I do think that not too many
> people know about auto-USE, so it is somewhat under-utilized.


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] coveted features

[Bart Lauwers]

Pieter,

 Imagine the expert system is 'screen' or interacts similarly to it, meaning 
it can read all output from portage and it can send a command line back (i.e. 
emulate a real user). This would basically put the system out of portage so 
why make it a requirement? So that during development it can be accounted for 
that some things will want unfiltered output and input. Maybe I'm not making 
myself clear again so let me know if you still don't see what I mean now.

I would in no way expect portage to deliver the expert system but it should 
IMHO provide the frame on which one could be built.

Bart

> > 8. have hooks for an expert system that can deal with compile errors
>
> This request is too abstract. This could become very interesting in
> combination with the freshmeat sync feature that was requested on -dev
> earlier. This is why I like looking at ebuild in a directory as a
> knowledge base (KB):
> there are learning techniques which can be used to , based on 'past'
> knowledge, provide about-data (dependency info, features, ...) for a
> newer version. The problem however is the howtodata (some patches might
> no longer apply, ...) it would be nice to have a reasoning system for
> that too, but I think this falls outside the scope of the current
> effort.


--
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] Re: [gentoo-doc] Re: [gentoo-portage-dev] coveted features

[Sven Vermeulen]

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

On Mon, Dec 29, 2003 at 06:55:50PM +0100, Bart Lauwers wrote:
[...]
> Anyway we've got lots of docs but were lacking a good taxonomy for them,
> do we have any librarians helping the docs team? (cc'ing doc to get a reply
> about this)

Librarians? Not that I know off... What do you mean with taxonomy?

> So let me rephrase that portage docs need to be complete and up to date at
> all times (at least an english version, devs should know enough english).
> Linking the documentation to the code is the only way I can see this happen.

Creating documentation automatically always reduces the readability of the
documentation. It all depends on who's the intended reader. If it is a
developer (and *only* a developer) then creating documentation automatically
might be suggesteable (although not official as there is no QA on it - don't
dare send me bugreports on automatically created documentation :)

If it also involves users, then sorry, I don't think this is a good idea. 

Wkr,
	Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

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

Re: [gentoo-portage-dev] Re: [gentoo-doc] Re: [gentoo-portage-dev] coveted features

[Jeremy Maitin-Shepard]

Sven Vermeulen <swift@gentoo.org> writes:

> On Mon, Dec 29, 2003 at 06:55:50PM +0100, Bart Lauwers wrote:

> [snip]

>> So let me rephrase that portage docs need to be complete and up to date at
>> all times (at least an english version, devs should know enough english).
>> Linking the documentation to the code is the only way I can see this happen.

> Creating documentation automatically always reduces the readability of the
> documentation. It all depends on who's the intended reader. If it is a
> developer (and *only* a developer) then creating documentation automatically
> might be suggesteable (although not official as there is no QA on it - don't
> dare send me bugreports on automatically created documentation :)

> If it also involves users, then sorry, I don't think this is a good
> idea. 

Indeed, in my experience, documentation generated by Doxygen is very
rarely of decent quality.  Provided that people are willing to write
documentation from time to time, ``hand-written'' documentation is
generally of higher quality.  If you just want a function reference, it
works, but compare the documentation in linux/Documentation to the
garbage you might get if you were to generate Doxygen documentation from
it.

-- 
Jeremy Maitin-Shepard

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: [gentoo-doc] Re: [gentoo-portage-dev] coveted features

[Bart Lauwers]

> > Creating documentation automatically always reduces the readability of
> > the documentation. It all depends on who's the intended reader. If it is
> > a developer (and *only* a developer) then creating documentation
> > automatically might be suggesteable (although not official as there is no
> > QA on it - don't dare send me bugreports on automatically created
> > documentation :)
> >
> > If it also involves users, then sorry, I don't think this is a good
> > idea.
>
> Indeed, in my experience, documentation generated by Doxygen is very
> rarely of decent quality.  Provided that people are willing to write
> documentation from time to time, ``hand-written'' documentation is
> generally of higher quality.  If you just want a function reference, it
> works, but compare the documentation in linux/Documentation to the
> garbage you might get if you were to generate Doxygen documentation from
> it.

Only developer documentation obviously. But auto generated docs don't have to 
be bad, most of the kde programming docs are done on the fly and they are 
more then decent. They're also complete and consistent. In terms of API 
documentation kde rules, can't we mimik this? (And sorry I kinda felt this 
was obvious in the request but I do mean a documentation level which isn't 
maintained by the doc team nor meant for general consumption but a reference 
guide for devs. And then still split in 2 levels, with one for portage 
development/ integration and one for ebuild developers.) And consumer doc 
writers are allowed but not forced to use the API level docs for 
reference. :) (Well I'm convinced it would make things better on a lot of 
fronts to have tighter code/doc integration but maybe there is a better way.)

 Bart


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: [gentoo-doc] Re: [gentoo-portage-dev] coveted features

[Bart Lauwers]

On Monday 29 December 2003 20:22, Sven Vermeulen wrote:
> On Mon, Dec 29, 2003 at 06:55:50PM +0100, Bart Lauwers wrote:
> > Anyway we've got lots of docs but were lacking a good taxonomy for them,
> > do we have any librarians helping the docs team? (cc'ing doc to get a
> > reply about this)
>
> Librarians? Not that I know off... What do you mean with taxonomy?

 What do I mean with taxonomy. The schema for orderly classification of 
documentation in a library. A library can be digital in fact our docs and our 
website ensemble is a library. Such a schema usually assigns relationships to 
documents based on natural or presumed relationships. A taxonomy is a tool to 
make information retrievable by humans without a search engine. In computer 
based libraries, taxonomies can combine different views or viewpoints without 
making things messy. 

 Anyway I'm not a librarian but I can recommend some reading if you're 
interrested in buying a book on the topic of what is a taxonomy. I once 
worked with a bunch of librarians and I found myself needing to read this 
book on what my collegues were talking about. Anyway the book is on my office 
shelf but I can forward the title and author tomorrow if you like.

 According to Merriam-Webster.com it means:
1 : the study of the general principles of scientific classification : 
SYSTEMATICS
2 : CLASSIFICATION; especially : orderly classification of plants and animals 
according to their presumed natural relationships

 Bart.



--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: [gentoo-doc] Re: [gentoo-portage-dev] coveted features

[Jeremy Maitin-Shepard]

Bart Lauwers <blauwers@gentoo.org> writes:

> [snip]

> Only developer documentation obviously. But auto generated docs don't have to 
> be bad, most of the kde programming docs are done on the fly and they are 
> more then decent. They're also complete and consistent. In terms of API 
> documentation kde rules, can't we mimik this? (And sorry I kinda felt this 
> was obvious in the request but I do mean a documentation level which isn't 
> maintained by the doc team nor meant for general consumption but a reference 
> guide for devs. And then still split in 2 levels, with one for portage 
> development/ integration and one for ebuild developers.) And consumer doc 
> writers are allowed but not forced to use the API level docs for 
> reference. :) (Well I'm convinced it would make things better on a lot of 
> fronts to have tighter code/doc integration but maybe there is a
> better way.)

The quality of the documentation produced by doxygen and similar
documentation collectors/generators is generally much higher for very
object-oriented code; this is why the Java standard library
documentation generated by Javadoc is quite usable, and very likely why
the KDE documentation is very good. (I will take your word for it, I
have not looked at it myself.)  If portage-ng is written in a very
object-oriented way, then it is possible that Doxygen-generated
documentation will be of reasonable quality (provided that sufficient
comments are added to the code).  Otherwise, some manually written
documentation describing certain components or the interaction of
certain components would probably be at least a useful supplement.
Indeed, it is in describing the interaction between different
components that generated documentation, even of highly object-oriented
code, is often less useful.

-- 
Jeremy Maitin-Shepard

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] coveted features

[Jason Mobarak]

A tool I use for Python code is epydoc, which is very similar to javadoc, except
is uses reST (restructured text). So epydoc is my suggestion if Python is used
for portage-ng (or part of it).

On 18:55 Mon 29 Dec     , Bart Lauwers wrote:
> All the more reason to build the docs from the code directly with doxygen or 
> whatever. I'm pretty sure nobody writes code with the intent it doesn't get 
> used, from a coder standpoint having documentation helps feature acceptance.
> 
> This feature probably is documented but since I can't find that documentation 
> quickly (i.e. just could find it in under 5 minutes) it might as well not 
> exist to the majority of devs. We s'port too many hidden feats.
> 
> Anyway we've got lots of docs but were lacking a good taxonomy for them, do we 
> have any librarians helping the docs team? (cc'ing doc to get a reply about 
> this)
> 
> So let me rephrase that portage docs need to be complete and up to date at all 
> times (at least an english version, devs should know enough english). Linking 
> the documentation to the code is the only way I can see this happen.
> 
>  Bart.
> 
> On Monday 29 December 2003 00:02, Daniel Robbins wrote:
> >
> > This results in the current USE settings. I do think that not too many
> > people know about auto-USE, so it is somewhat under-utilized.
> 
> 
> --
> gentoo-portage-dev@gentoo.org mailing list

-- 
------------------------------
~~~~~ Jason A. Mobarak ~~~~~~~
~~ aether_at_gentoo_dot_org ~~
~~~~ jmob_at_unm_dot_edu ~~~~~
------------------------------


--
gentoo-portage-dev@gentoo.org mailing list