On Sun, 2008-10-26 at 22:18 +0100, Hans de Goede wrote: > Jeremy Katz wrote: > > On Fri, 2008-10-24 at 11:12 +0200, Hans de Goede wrote: > >> 3) Add a "make test" target which calls PyChecker and possible does other tests > >> and add "make test" as %check to the spec file. > >> > >> Yes this means that having something which PyChecker does not like will break > >> the build, this is intentional. Its better to have an old working build (with > >> known bugs) in the tree for a day longer, then it is to have a new build which > >> has known new issues (potentially of the will not install at all type). > > > > The only reason I see for not doing it at build time (and failing the > > build) is that we end up getting the errors from packages we don't > > control potentially failing our builds. gcc -Wall -Werror we've done > > for a long time because everything there is "our" fault... but > > pychecker, etc will also fail due to errors in pygtk (or > > $insert_other_python_module_we_use_here) > > > > pychecker can be passed a list of modules to ignore. That's a nice addition from the last time I used it and makes it at least more palatable to run at build-time. Having a list of modules to ignore is backwards, though -- we only want to care about problems in our code. Having to update a list of modules to ignore is going to be error-prone and just another thing to get out of sync with reality :-/ But c'est la vie I guess. > >> 4) Add more automated validation in the build process where possible, for > >> example we've been seeing quite a few bugs in rawhide due to fonts going > >> missing. There are 2 things which I want to do here: > >> a) Verify that all the packages which we ask yum to install into the install > >> image root, actually have gotten installed > > > > We (intentionally) keep old and new package names in the list so that we > > are slightly flexible about the environment in which we're used. > > Hmm, to me this feels more like a kludge the something desirable. It's not a kludge, it's because there are people that genuinely like to take "new" anaconda with an "old" distro and mash them together. For a lot of cases, this works. Granted, not all. But it's something I'd rather not be actively breaking > >> b) Not only keep files on the keep list, but also check we actually have all > >> the files on that list in the root, so that if files get moved to a subpackage, > >> etc. We *automatically* catch this at the first build. > > > > Arguably, we should move to just telling yum to install packages by > > specifying the files and not the packages. > > Could do, but that is going to be pretty slow, and to me this does not feel > right. We do want certain packages IMHO, not certain files, but the keepfiles > list is a hack to work around some packages not being split up fine enough IMHO. That's just it, though -- we don't care about the "package" in a lot of cases, we do actually care about the file. Either because it's an executable we run or a font we care about or ... > Which make me think, that maybe we need both a keepfiles and a removefiles list > and error out if: > 1) a file on the keepfiles list is not found > 2) a file on the removefiles list is not found > 3) a file is installed by yum which is in neither list > > This way we can quickly detect any package changes and see what we should do to > adapt. This basically means that we're keeping a copy of what every single file we're including or excluding from every package we use. This means rawhide will never happen. ;) Because people are going to change packages and not notify us. And I don't think we really want to keep up with it either even if they were. > >> And yes again my proposal is to fail the build if any of these checks fail. > > > > Failing the rawhide build for something like this is somewhat > > counter-productive. Sure, it points to the fact that a Japanese font > > changed. But the downside is that it means that we can't get testing of > > anything else that day. Which, since many of these sorts of things are > > out of our control, basically means that we don't get to do our testing > > some non-trivial percentage of the time. > > Nobody is stopping the person from submitting the build, to actually watch it > progress, check for errors, fix then and resubmit the same day. This is tree build stuff, not package build. So it happens at $late_at_night_us_time; not just something that can have its progress watched and resubmitted. It's not practical to check it at package build time because the packages that are present may well be different by the time the tree is composed Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
