Re: RFC: Keywords instead of Section
> the type is important to make it more organized. having the list of
> allowed types helps a great deal to keep it tidy. and unless it is
> maintain and clean it is of no use and waste of time.
because you brought the example of programming languages, i'll reply
with the same example.
The type is purely cosmetic.
Typing Variables is merely a syntactical sugar keeping you from doing
mistakes while programming; the generated binary does (usually) not know
about data types at all.
> where is the difference? debian packages are very tightly controlled,
> they are well maintained and are required to complain with policy.
So i come back to my orginial postulation:
- the package format and software must not know about types
- the keywords list must be maintained by a commitee
(they do have to do the classification, definition and description of
keywords, and they surely will type them themselves)
- the frontends must present the keyword selection in an useful manner
(so they'll use types, too, but they might even use different
groupings; they might to hide keywords with just a few packages etc.)
> not sure what you mean here? what I said that it's neccessary to have
> some metainformation about types, at least description, which is the
> same thing as you are saying, if I understand it correctly. Of course,
> to store metainformation about types you need to store the type names
> somewhere...
That's what the keyword-comitee and their list is for.
the software shouldn't care about this, so it doesn't need to be
updated.
> the menu system to not to know what policy says is not good.
incorrect. the menu system is mostly independant of the policy, and
thus doesn't need to be changed when policy changes.
It would better be lintian's job to check the menu files.
> that's the same situation as you have with everything else! libraries.
> or any other fiels used by more than one package. you cannot (should
> not) mix packages from different distributions. that's basic assumption
> of debian (or basically any other versioned system).
i disagree.
One of the major points of dpkg is that it checks these dependencies, so
you can actually run applications and packages from other distributions
if you fulfill the dependencies.
> by many packages does not have much sense (therefore adding a keyword
> should be fairly rare action).
incorrect. Think about "berlin" for example - there is currently no much
use to add a new keyword for ui:berlin.
But once Berlin Applications start appearing, we will need such a
keyword. Other new keywords we could use are: python1.5 python2.0
python2.1 python2.2
So i believe that there will be new keywords appearing every month.
> no, we get a messy system (again: see deb <-> rpm). we need a
> manageable system, that is also dynamic and adaptable (i.e. that roughly
> means that you want user defined types)
Lots of the good things of deb <-> rpm are in Policy, not in the
software, i think. If you do not set good dependencies etc. you do not
gain anything. If you set bad dependencies your software becomes
uninstallable ;) Same should be with keywords: if you do set good
keywords (i.e. master keyword list compliant) people will find your
software easily, if you do not, people will just not find your software.
> the purpose of keywords and types of keywords is to make the whole
> system of huge amount of info about packages organized. To make it
> possible you need the keywords and their types organized in the first
> place. Otherwise it's useless...
We are not arguing about the need to categorize, group and put the
keywords into an hierarchy. We're arguing about who needs to know about
this hierarchy.
Same with menu, which you brought up before.
Menu should not care about what hierarchy it has do deal with.
It should be a simple menu-files -> window-manager-menu converter.
> is very useful (necessary even) to have separate information about
> keywords - those would be simply policy decided default keywords (with
> description, some of them required and other metainfo).
See my proposal.
Gruss,
Erich Schubert
Reply to: