Re: RFC: Keywords instead of Section
* Erik Steffl <steffl@bigfoot.com> [011118 23:13]:
> you need to have information on types separate, if nothing else to be
> able to check the type - how do you know it's a valid type if you don't
> have the list of types (think of the first category in given type).
Read wha I wrote: I'm of the opinion, that to cathegorize packages,
it is better, if there are no invalid types. The type has no other
meaning as to enable some package-choser to look for packages with
keywords of this type.
While in any programming language I would prefer well-defined types,
there is no reason to add extra overhead with type-definitions here.
If the system is able to handle additional types on the fly, then there
ARe no semantically invalid types, they may only be invalid through
syntax, as %&$_1 should be no valid type.
> you
> need to be albe to work with types independently, store some
> metainformation about the type (at least description, see also (very
> short) dicsussion on derived types etc.) etc.
I do not know, ff descriptions are necessary to cope with indexed
packages. To index them correctly, you need some Description.
Look at the menu-system for example. An user does not need the
information, which sub-menus exist and how they are defined. And
consequently the menu-system does no have any assumptions on which
sub-menus exist and woule make no Trouble to add an "AppsForFun" between
"Apps" and "Game". These are handled by policy, as devlopers have an
list, what belongs to which menu. And lintian may check, if the menus
some package provide fit into policy.
But any local package can have its own extensions, e.g. On my system I
have Apps/openoffice/..., which can only be found in the package for
these, I had not to add any global metadata on any machine I installed
it.
> having the type sort of implicit in the name is a dirty hack that will
> cause problem in the future. the things that are separate should be
> separated - that's one of the basics of programming (if not THE basic
> element of programming).
But the other basic element of programming to to clue together, what
belongs together.
Your argument are programming languages. There I agree, that explicit
type-definition are a very good thing. But here the situation is
something else.
There is no good reason to forbid the same names
within different types, licence:X11 and ui:X11 would give no additional
benefit, if renamed into licence:X11licence and ui:X11 or something like
this.
And there is no need to have types well definied. Look e.g. at the
"Section:"-field of the current packages. There is a limited variety
of values for it in official packages. But there is no reason not to
cope with others. aptitude for example hasno problem to correctly
display my packages with "Section: local" the same way like "Section:
main" within its own tree.
If I had had to edit some global section-definition on every computer
in this institute, that uses these local packages, then they would
have gone into some of the existing cathegories, where they fit neither
very well, and my successor here would have to seek out the hard way
what is what...
> btw: what you describing is extremely BAD thing. you don't want
> anybody to screw up the types, they only have value if they are well
> maintained. If it will prove absolutely neccessary to have custom types
> we might add this possibility later (in some systematic way).
As I describes with the menu system and the sections of packages, I do
think that it is no bad thing at all, if there are good rules for it.
I agree, that there should be a well defined set for types and values,
any offical debian package has to keep within.
But image there get some type added betweed woody+3 and woody+4 ( let
me call them foo and bar). If you have the tools of foo, they know the
old types and may render other types invalid in you approch. Then I
take some package of bar, and make foo-packages of it. (This is a very
likely situation, there are many people running potato know, with many
of the packages of woody and sid compiled on them).
But the package of bar will have an good chance to declare the new type,
perhaps because it is some kind of software noone thought before of.
With well defined types, you have problems here. You would have to
add some config file, or even get the package managment tools of bar.
Therefore my conclusion is:
There is no real gain in having pre-defined types and values, except
the savety contro screw ups. But none of the system without pre-defined
values we currently have, has seen screp-ups.
By not having pre-defined and seperately defined types and values, we
get an dynamic and adaptable system. And this is a Good Thing[tm] in
my eyes.
Hochachtungsvoll,
Bernhard R. Link
Reply to: