Re: RFC: Keywords instead of Section
"Bernhard R. Link" wrote:
>
> * 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.
well, I read that part but I thought that my opinion on that will be
aparent without explicitly stating it. here it goes:
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.
as a real world example observer the redhat style packages and debian
style packages. it is general consensus that deb is the best thing ever
happened to linux distros since birth of linux and that rpm simply mean
neverending problem with dependencies.
at the same time deb and rpm formats are bascially equivalent - what
you can do using deb does not significantly differ from what you can do
using rpm.
where is the difference? debian packages are very tightly controlled,
they are well maintained and are required to complain with policy.
> 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.
there are other ways to add user defined types to the system. that
does not mean you cannot have basci debian types defined and mostly
used. You can have additional types, if neccessary.
> > 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.
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...
> 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.
menu system is wonderful; but IMO it would help a great deal if info
about menu categories (menus and submenus) that is defined in policy
were part of the menu system itself. Along with descriptions. That way
it would be much easier to change policy, to enforce policy etc.
the menu system to not to know what policy says is not good.
related: policy should be implemented - as much as possible should be
actually usable by programs. That's basically what linthian does but IMO
it should be part of the tools that developers use (notice that most of
the lint is now part of tools developers directly use - compilers - so
the need for a separate tool is diminished).
> 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.
if neccessary, it might be possible to implement type system (and
menu, which is similar problem) in a way that makes it possible to
define user defined types (submenus). it's no big deal. The point is
that the basic types are there and generally used. If you want to do
something with your system you should be able to do it, so I guess user
defined types should be implemented.
> > 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.
that's what comes naturally:-) that hard part is to separate parts and
define interfaces between these, that's why I emphasize that part...
> 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.
having defined types does not mean you cannot have two keyword values
that are same for different types.
> 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...
as far as I can tell you needed a new vallue, not new type here.
but it doesn't really matter, the point here is that yes, the type
system has to allow users to define types. That does not mean you cannot
have types defined by policy.
However the official debian packages should be compliant with policy
that would state which keywords are required (and it would state it in a
form directly usable by programs).
> > 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.
it is worse than bad. think of it as difference between debian and
redhat package system.
If you have 4 packages and 3 people working on them you can go with a
system that is based on no rules. However if you have the number of
packages debian has (and that number is not going down, it wil probably
go up) you have to have a well organized system. The system has to be
well thought out and flexible enough to allow changes in future as well
as being changed by local users (admins). But you still need a well
organized system, with explicit rules that are enforced.
> I agree, that there should be a well defined set for types and values,
> any offical debian package has to keep within.
agreed:-)
> 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.
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).
note that new kind of software that nobody ever thought about would be
likely to add a new value, not keyword. having keyword that is not used
by many packages does not have much sense (therefore adding a keyword
should be fairly rare action).
> 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.
that's not true. just look at the menu system. the programs are where
they shouldn't be. the new sections are not created because there is a
huge gap between policy and program itself.
why is the evolution in Tools while other email tools under Net?
XShells have mostly terminals but also tkdesk and tkworld which are more
like file managers that are in system (nautilus), tools (mc) and
probably someplace else... why is text on my system almost empty (only
fortune)? I have huge number of text only programs... what is text menu
entry for anyway? will menu tell me? no, because menu entries are not
managed by menu but instead by policy (to which menu does not have
access). doesn't look good (after only very cursory overview).
> 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.
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)
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...
note that the whole discussion above is sort of beside the point:
regardless of whether random keyword types and keywords are allowed it
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).
> Hochachtungsvoll,
zo srdecnym pozdravom, (I know what hoch means, also what achtung
means but I had to google the net to find out that hochachtungsvoll
means respectfuly/Yours sincerely/Yours truly/Yours faithfully)
> Bernhard R. Link
erik
Reply to: