On Wed, Sep 14, 2011 at 11:46:24AM +0200, Marc Espie wrote: > On Tue, Sep 13, 2011 at 10:53:47PM +0000, Kevin Chadwick wrote: > > On Tue, 13 Sep 2011 16:21:06 -0400 > > Brad wrote: > > > > > Then said users put the manual work in to manually build certain > > > packages using pseudo FLAVORs and such to cut down on building or > > > just build them in the same manner as a bulk build. > > > > > > No big deal just a let down after seeing evince build time being > > reduced and wondered if there was a best of both. > > > > I'm guessing there's no quick and easy way for a bulk build environment > > variable to be picked up as bulk builders and maintainers are more > > likely to know to a greater depth, what they are doing? > > > > Still good to know installing poppler will save time.
To be a bit clearer: this has long been a (small) problem. - if we do make things faster for the casual tinkerer, then ports bulk builds go slower. - ports bulks going slower is a bad thing, as basically less bulks get done, and the main complain in this mail happens: slower = less frequent snapshots. - More flavors => bad. Conflicts may happen, even break bulk builds (dpb is smart, but it can't recover automatically if two thingies want distinct conflicting dependencies to build). There are countless examples of places where we moved flavors into multi-packages, or removed flavors altogether. Flavors are bad for the average user. Don't yell at me ! let me explain first. The average user is supposed to install binary packages. For flavors to make sense, there has to exist a binary package with the corresponding flavor. Thus, more build time. In case of too-many-flavors-disease, the exact flavor combination YOU need will most often not exist as a binary package, as per Murphy's law. Yes/no flavors ARE exponential in nature. If you have 4 flavors, we must provide 16 packages to cover them all (imagine each package taking an hour to build). So, we have multi-packages, AND pseudo-flavors for the tinkerer, so that you can build stuff "faster" if need be (requires a bit of tinkering). Bottom-line, it's a political choice. We chose long ago to favor binary packages over tinkering. One set of standard tools. Standard binary packages that people can install and update. "This is not the problem you're looking for". Making tinkering easier is not the solution. ESPECIALLY if you end up complaining about the lack of snapshots. Streamlining the process even more so we get very frequent snapshots is the solution. And since I'm not consistent: this long nagging issue of not being able to use pseudo-flavors in such a context might come to an end soon. Film at 11.
