On Sat, 22 Jan 2005 01:12:10 -0600 Daniel Goller <[EMAIL PROTECTED]> wrote: | > Ok. It'd probably help if you two let everyone know which eclasses | > you work with on a regular basis so that we can figure out how this | > relates... The problems you describe don't seem relevant to any of | > the eclasses I work with, but maybe the ones you use are different. | | do i have to meddle in an eclass to be able to point out that one | version that is never constand used by many versions of ebuilds cant | be a good thing? im not sure what it is you are after here
I want to know what problem you're trying to solve. If you don't work
with eclasses, it seems to me that you probably don't have a very good
idea of what you're dealing with. As someone who *does* work with
eclasses, I can assure you that I'm not encountering any of the problems
you're trying to solve.
| can you already control that changes to an eclass do not affect a
| certain version of a package, if that package uses an eclass that has
| changed several times significantly in the version specific part,
| while the ebuild version has not?
Sure. I've been doing that for ages for *vim.
| it is great we can do that (if
| people only used it), what the issue is here that two people can
| merge the same package version at different times and due to
| different versions of the eclass do not get the same results, during
| merging and or after
|
| ie emerging foo-1.2-r1 in may should yield the same result as merging
| foo-1.2-r1 in july, while it doesnt
That's up to the developer. Ideally, if they are making significant
changes, they'd revbump and do version conditional code on the change.
| if you find this then means policy/how we do things should change not
| any existing technology, im listening
No need to. versionator can do this already.
| i just happen to prefer a solution like 'cp foo-1.2.eclass
| foo-1.3.eclass && vim foo-1.3.eclass' a lot better to control than
| hoping that "they just do it right", maybe you have more faith in the
| people using eclasses than i do at this point? :)
Maybe I understand how much of a nightmare trying to keep that in sync
would be, and how much easier it is to have a really short if block
doing something like:
if version_is_at_least 6.2-r1 ; then
# we also install the docs with this release
use docs && make DESTDIR=${D} install extra-docs
fi
Than two entirely different eclasses.
Remember -- if code changes wildly between versions, it belongs in the
ebuilds, not in an eclass.
| again this is not that im limited to work on my eclasses, it is about
| how there should be more care about how we deal with eclasses, since
| one eclass can break many packages or even archs it wasnt tested on
| (of course that shouldnt happen, but it does, and we can talk about
| how to minimize damage once a pourly tested commit was made, and of
| course emphasize that such shouldnt happen)
...which is why we do testing. If you find that a particular developer
*isn't* doing proper testing, talk to them. If that doesn't work, talk
to devrel.
| i think we agree here that testing should be done, and proper QA might
| have avoided this thread from ever starting, i think versioned
| eclasses could lead to reduced man hours for thorough testing while
| dramatically increasing the gain in quality of our product
And I think they'll lead to a coordination nightmare and that
range-based code which can be done with existing tools is a far cleaner
solution. Of course, Stuart-style versioned eclasses are always an
option too for things that *are* huge changes, and they don't need
anything added to portage either.
| a simple cp from one version of eclass to the next doesnt take long,
| we know the old version of the package foo, worked with the eclass
| version it inherits, and we no longer touch it, the new version
| eclass is then only inherited by future version of the package foo
| the bumped package foo that in herits the bumped eclass foo would end
| up in ~arch, where it can be thoroughly tested
| avoiding unnecessary compiles for our arch customers, while keeping a
| downgrade path for our ~arch customers open
| even if it is from a ~arch to ~arch bump, we shouldnt inconvenience
| our ~arch customers any more than our arch customers when it comes to
| predictability of their systems
Yes, but we can do all this without a cp as well, and it has the added
advantage that we won't have to keep track of hundreds of files.
| > | * All files in portage should have checksums. Unversioned files
| > | will be very hard to track reliably. If every change in the file
| > | causes a version bump eclass integrity can be verified by the
| > | users without checksum consistency problems ("it was F5D123
| > | yesterday, today it checksums to E47DDD, so it's been hacked")
| >
| > Uhm... Checksums? We don't sign eclasses anyway just now, since
| > portage doesn't support it. For versioning, all eclasses should have
| > a CVS $Header$ line.
|
| like we said, it would be nice version x.y of eclass foo really hasnt
| changed, but that is a technicality to be solved down the road, for
| now, we would get it figured out which the least straining way is to
| really get predictability increased multifold
Right, so you admit that you just threw in the security thing in the
misguided hope that no-one would notice that it's not relevant?
--
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
pgpJ96W17pt51.pgp
Description: PGP signature
