Robert Buchholz wrote:
Steve Long wrote:
Robert Buchholz wrote:
The problem here is that one can not say when the whole tree is updated
to the new standard, because for the packages which were not touched, it
could mean that they needed no change or that they were not looked at
yet.
I can understand that as a maintenance issue. My query is whether having
two different types of pkg would effect users in any way.
You're right, it would not be a problem for usability.
Well that makes a change ;) Although it sounds like a maintenance nightmare.
A solution to distinguish the two categories is to mark the packages
which were checked, so you know:
1. If it's checked and doesn't depend on cc - category 1
2. If it's not checked and doesn't depend on cc - category 2
Then, when all packages are checked, the tree is upgraded.
Sure, that makes sense. It sounds a heckuva lot like a database ;)
Minor point- how can you tell in cat 2 that it definitely does not need a
C compiler if it hasn't been checked? I'm guessing you were tired :) In
any event in terms of maintenance, we'd need a tri-state: unchecked,
checked and needs compiling, checked and doesn't (eg scripts).
No, no. I did not mean that category 2 does not need a C compiler. I
referred to Alec's mail which had 2. Packages that don't yet depend
upon C-compiler.
As for the state problem, when saving checked and unchecked as a
package's metadata, you will get the other properties (needs cc, needs
insert system dep) out of its DEPEND.
Alec Warner wrote:
1. Packages that don't require C-compiler
2. Packages that don't yet depend upon C-compiler
When doing the upgrade over a period of time the two classes of package
become indistinguishable. Does Foo not need a C compiler, or has it
just not gotten updated yet, it's impossible to tell without looking, so
it's very difficult for people to report 'problem packages' because they
have to unpack and examine the package every time (at worst).
I understand that it's hard to distinguish a pkg that hasn't been checked,
but might need the C-compiler, from a pkg that doesn't need the compiler
but just hasn't been checked. That's where I was going with the database
stuff.
In terms of maintaining the metadata, am I right in thinking it's all
just kept within the text files in the tree?
Since the tree itself is the best database of the packages available,
anything else would be a lot more overhead.
I really don't agree, altho I could well be missing something. Surely there
should be a maintenance/QA database which tracks the tree and where you
could put information like this (ie a boolean flag for this instance) which
simply shouldn't be exposed to users. There's no need for it, it doesn't
effect them, and why should it go in the ebuilds where a maintainer might
delete it?
But I had the impression the idea was discarded anyway. So I should
focus my thoughts somewhere else :-)
Please focus your thoughts wherever you wish. I gotta ask tho; what idea? I
thought we were just talking about excess dependencies in the tree.
May your thoughts be pleasant :)
--
gentoo-dev@gentoo.org mailing list
