Hello, On Thu, Oct 16, 2014 at 08:47:19AM +0200, Andreas Tille wrote: > > Would this use case also be a reason for creating a personal blend? Or > > even an official one? > > Jonas has answered this question. I'd like to add that I'm no fan of > "personal" things since you spoil the idea of forming a team around the > idea. Yes, I agree. However, sometimes the needs are so specific that it doesn't make sense to do them on a larger scale. I'd make the packages public, but I wouldn't suggest that a blend for very limited use deserves a prominent position in the installer. But as Jonas pointed out, if the blend only does the setup for running a single application and any application can be chosen at install time, that increases the audience to a point where it may deserve that position. I'll consider if I want to drive that effort. I'd really like to see this happen, but I'm also trying to limit new projects I start, so that I have enough time to handle the things I do properly. If more people (besides Jonas) are interested, please let me know privately. If you want to be the driver, definitely let me know, too. :-) I'll send a status update by the end of the month. > Well, these are good questions. They are abit hard to answer in a > situation when we are discussing about how to properly install the > currently existing Blends. Indeed. Someone should remember to bring them back up once that question has been answered (and the answer has been implemented). > > So it installs a package which changes configuration of other packages > > when it is installed? That sounds very ugly... Isn't there a better > > way to preconfigure a system? > > Yes. The better way is to convince the single package maintainers. The > longish discussion is in bug #311188. Reading that raises questions regarding the configuration editing tool I wrote about some time ago. I'll follow up to that thread (on -devel only). > > Oh, and I have another question; this seems very similar to "tasks"; how > > is it different? > > Each Blend creates metapackages and a <blenname>-tasks package to feed > tasksel. Yes, we are using this term actively. The difference is more > in the content that the tasks are specific for fields of interest but > the used technique is the same (which is intentional to enable > integration into the installer easily). Ok. Is it supposed to be possible to install more than one blend simultaneously? Is that technically prevented with Conflicts? > > > Enhancements / patches(source is in package source of blends source > > > package) are always welcome. > > > > I might write a patch, but knowing myself I probably don't get around to > > actually do that. > > ... as always with documentation. :-) The same applies to me to some > extend (and I'm not proud about this). No, I'm not proud of it either. But as Feynman said: "you [yourself] are the easiest person to fool." So I take some pride in admitting it; telling myself otherwise would have been easier. ;-) Thanks, Bas
Attachment:
signature.asc
Description: Digital signature