Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 19:04:41 (CEST), Andreas Tille wrote: On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote: several user groups. If there are applications which are useful for more groups just list the application in question for all of them. Interesting. Is there some easy way to query in what tasks a given package is used? I'm just using grep on the tasks files in SVN. IMHO for developers this is OK. Do you have any other purpose in mind? Right, for the developers with a recent svn checkout, that might be enough. I was thinking about users that don't have such a checkout available, but I don't have an important use case in mind right now. is fullfilled if only one of them is installed as well as if you can also use Suggests: not so important package which IMHO are two important advantages over the tasksel approach. At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? I tried to enable selection of Blends tasks immediately after installation (see bug #186085) but failed. So for the moment you just install the metapackages as any other package with your favourite package management tool. Mmh, it seems that everyone agrees that Blends (it was called CCDs at that time) should provide their specialized installation media, and I'd agree. But if we have such an installation media, the whole concept of metapackages feels strange to me. At installation time, we have much more control about what is installed anyways. BTW, do Blends provide their own, customized installation media? What about live CDs? We should probably make a FAQ about this. The answer is: There *should* be a script to simplify this but probably it does not exist yet. Somebody has prepared something for Debian Med at svn://svn.debian.org/svn/debian-med/trunk/community/infrastructure/livecd In principle metapackages make the lice CD preparation quite simple by using live-helper but I would be really happy if somebody would write a generalised script + configured hooks which just needs a blend-build-livecd blendname and similar with to build d-i images. It's just a matter of finding the nneded time to do this, but in principle it should not be that hard. Hm, if there is neither of them, what makes a blend a product? There must be more than a couple of metapackages... Looking at the existing blends, it seems that Blends currently really mainly consist of a handful metapackages maintained by a respective developer community doing marketing and package maintenance. Seems that I expected something like a product instead. But anyway, it seems that Debian Live has made a lot of progress for squeeze. And if the live installer prooves to be working, maybe (some) blends can go with Live CDs only. Another thing that might be quite important would be some proper documentation for the blend in general. That should probably include installation, maintenance and user guides to the most important featured applications. About what content are you thinking of at this point? Multimedia related packages which are in Ubuntu or debian-multimedia.org but not (yet) in Debian. I guess there are some of them, but I'm not that deeply involved in this field. Oh, I don't think we have the ressources to actively look for new cra^Wstuff to package, but rather already have more enough packages to look after. But in general, sure, if someone notices a great new candidate, we'll of course adopt it under the team umbrella. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 22:45:39 (CEST), Andreas Tille wrote: On Tue, Aug 17, 2010 at 08:33:45PM +0200, Jonas Smedegaard wrote: At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? By tasksel. Correct me if I am wrong, Andreas, but I believe it works exactly like a standard old-fashioned metapackage, and that the difference is in how it is maintained (i.e. developed) and what *additional* uses it has maintaining package relations like this. Not completely right. Blends-dev creates a blend-tasks package which contains a tasksel control file which works with tasksel. I personally did not used this tasksel option because the only use *I* see would be in replacing the default tasks in d-i (or adding them to default tasks). Because this was not accepted by tasksel maintainer I *personally* go with the single metapackages because they allow more fine grained selection (as it was explicitely requested here with alternatives). It seems to me that tasks in tasksel cannot be combinated sensibly. Metapackages work around this problem, but also only if they are installed afterwards. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Wed, Aug 18, 2010 at 09:50:01PM +0200, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 19:04:41 (CEST), Andreas Tille wrote: On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote: is fullfilled if only one of them is installed as well as if you can also use Suggests: not so important package which IMHO are two important advantages over the tasksel approach. At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? I tried to enable selection of Blends tasks immediately after installation (see bug #186085) but failed. So for the moment you just install the metapackages as any other package with your favourite package management tool. Mmh, it seems that everyone agrees that Blends (it was called CCDs at that time) should provide their specialized installation media, and I'd agree. It was not called CCD but CDD: Custom Debian Distribution But if we have such an installation media, the whole concept of metapackages feels strange to me. At installation time, we have much more control about what is installed anyways. The common development proces in Debian rarely focus on a larger range of packages working together, but mostly on either single/few packages at a time or everything. The proces of composing Debian Pure Blends helps here. Ideally it should not matter if in the end you install your Blend using a standard Debian DVD or a custom rolled out USB memory stick - the experience of an integrated effort should be similar. So when you ask specifically is it a custom CD? or the opposite is it not a custom CD but 'just' a task in standard tasksel of the Debian DVD then the answer is the same: yes, it can be that. Try read the responses from Andreas again in that light - I suspect it will then make more sense :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote: several user groups. If there are applications which are useful for more groups just list the application in question for all of them. Interesting. Is there some easy way to query in what tasks a given package is used? I'm just using grep on the tasks files in SVN. IMHO for developers this is OK. Do you have any other purpose in mind? is fullfilled if only one of them is installed as well as if you can also use Suggests: not so important package which IMHO are two important advantages over the tasksel approach. At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? I tried to enable selection of Blends tasks immediately after installation (see bug #186085) but failed. So for the moment you just install the metapackages as any other package with your favourite package management tool. Let's imagine the following depends in the 'multimedia-consumer' metapackage: Depends: mplayer | gxine | totem | kaffeine | dragonplayer | vlc I guess that if we the user first selects to install an KDE system in tasksel in d-i, and in that task kaffeine (or dragonplayer, not sure what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Yes (but untested). Assuming that an 'LXDE' task does not install any media player and is selected first in the installer, does the 'multimedia-consumer' metapackage only install mplayer and nothing else? Yes (also untested). If I get that correctly, this sounds pretty useful to me! If apt works as I expect it to work than this is exactly the case. Interesting. Just curious, did you have a look at the 'ubuntustudio-meta' source package? http://packages.ubuntu.com/source/lucid/ubuntustudio-meta. I should do this later. It's implementation might be different (it uses germinate), but it seems to me that blends-dev and germinate/ubuntustudio-meta share very similar goals, right? I imagine that we could use that at least as source of inspiration what multimedia tasks would be useful for a DeMuDi Blend. BTW, do Blends provide their own, customized installation media? What about live CDs? We should probably make a FAQ about this. The answer is: There *should* be a script to simplify this but probably it does not exist yet. Somebody has prepared something for Debian Med at svn://svn.debian.org/svn/debian-med/trunk/community/infrastructure/livecd In principle metapackages make the lice CD preparation quite simple by using live-helper but I would be really happy if somebody would write a generalised script + configured hooks which just needs a blend-build-livecd blendname and similar with to build d-i images. It's just a matter of finding the nneded time to do this, but in principle it should not be that hard. For comparison, ubuntustudio-meta in lucid creates these metapackages: $ grep -E ^Package debian/control Package: ubuntustudio-desktop Package: ubuntustudio-audio Package: ubuntustudio-graphics Package: ubuntustudio-audio-plugins Package: ubuntustudio-video Package: ubuntustudio-font-meta So this matches your suggestion pretty closely. Perhaps somebody could browse the list and adapt our tasks. I see. Well, I think we'd first need to get an idea what kinds of configuration options would be interesting for a DeMuDi Blend, but it's great to know that we have a place for this. :-) About what content are you thinking of at this point? Multimedia related packages which are in Ubuntu or debian-multimedia.org but not (yet) in Debian. I guess there are some of them, but I'm not that deeply involved in this field. Thinking further in this direction we could think about adding Debian-Multimedia.org package information to UDD and add this to the tasks page. Well, with the experiences we've made so far from bug reports, I don't think that we can endorse using that archive with good conscience. Well, we are not really *using* this but we are providing information about packages which can be used in principle by our users (they do it anyway). Moreover it saves us some work to maintain the metainformation about potentially interesting packages for our users in the tasks files explicitely. (This probably needs some detailed demonstration and is hard to explain in a short mail.) Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote: (CC'ing you, as I know that you are currently travelling) On Mon, Aug 16, 2010 at 09:42:04 (CEST), Andreas Tille wrote: There is no need to install a lot of applications on one machine. The blends-dev tools are building a tasksel control file which really would install everything in the task. This was used by Debian Edu and the functionality is keept - but there is no need to really use tasksel (even if the name tasks is inspired by tasksel). In Debian Med and Debian Jr. the usage of metapackages is prefered and there you have on one hand the alternatives option for instance Depends: mplayer | xine-ui | ffmpeg is fullfilled if only one of them is installed as well as if you can also use Suggests: not so important package which IMHO are two important advantages over the tasksel approach. At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? By tasksel. Correct me if I am wrong, Andreas, but I believe it works exactly like a standard old-fashioned metapackage, and that the difference is in how it is maintained (i.e. developed) and what *additional* uses it has maintaining package relations like this. Let's imagine the following depends in the 'multimedia-consumer' metapackage: Depends: mplayer | gxine | totem | kaffeine | dragonplayer | vlc I guess that if we the user first selects to install an KDE system in tasksel in d-i, and in that task kaffeine (or dragonplayer, not sure what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Beware that if *both* KDE *and* multimedia-consumer is selected during same installation routine (e.g. at initial install) then there is no guarantee which media-player, or how many of them, gets installed. Assuming that an 'LXDE' task does not install any media player and is selected first in the installer, does the 'multimedia-consumer' metapackage only install mplayer and nothing else? Beware that if first installing KDE + multimedia-consumer, and then at a later installation batch installs LXDE, then there is no ensurance (from multimedia-consumer) that any multimedia tools optimal for LXDE gets installed. Even uninstalling and later reinstalling multimedia-consumer does not ensure this. It is (during installation, at least) simply a metapackage! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 08:33:45PM +0200, Jonas Smedegaard wrote: At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? By tasksel. Correct me if I am wrong, Andreas, but I believe it works exactly like a standard old-fashioned metapackage, and that the difference is in how it is maintained (i.e. developed) and what *additional* uses it has maintaining package relations like this. Not completely right. Blends-dev creates a blend-tasks package which contains a tasksel control file which works with tasksel. I personally did not used this tasksel option because the only use *I* see would be in replacing the default tasks in d-i (or adding them to default tasks). Because this was not accepted by tasksel maintainer I *personally* go with the single metapackages because they allow more fine grained selection (as it was explicitely requested here with alternatives). what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Beware that if *both* KDE *and* multimedia-consumer is selected during same installation routine (e.g. at initial install) then there is no guarantee which media-player, or how many of them, gets installed. That's correct - but we do not have a reasonable way to control this (except with the debconf method I suggested previosely in the thread). Beware that if first installing KDE + multimedia-consumer, and then at a later installation batch installs LXDE, then there is no ensurance (from multimedia-consumer) that any multimedia tools optimal for LXDE gets installed. Even uninstalling and later reinstalling multimedia-consumer does not ensure this. It is (during installation, at least) simply a metapackage! That's correct. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Maintaining tasks files (Was: projectm 2.0.1+dfsg-3 MIGRATED to testing)
Hi, after subscribing this list I now get several e-mails about packages I just don't know which are obviosely relevent for multimedia issues but I just do not feel competent to put into the right task. Apt-cache told me that projectm has for instance a binary package libprojectm-dev which could be added to a (not yet existing) task multimedia-dev which might collect all those packages which are relevant to package multimedia applications (for sure there could be also more fine grained tasks for development issues created). In general I would strongly suggest: Please check out the tasks pages whether they are featuring your package and if not at least drop me a note to what tasks it should be added. Kind regards Andreas. On Thu, Aug 12, 2010 at 04:39:13PM +, Debian testing watch wrote: FYI: The status of the projectm source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 2.0.1+dfsg-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Fri, Aug 13, 2010 at 09:49:01 (CEST), Andreas Tille wrote: Hi, after subscribing this list I now get several e-mails about packages I just don't know which are obviosely relevent for multimedia issues but I just do not feel competent to put into the right task. Apt-cache told me that projectm has for instance a binary package libprojectm-dev which could be added to a (not yet existing) task multimedia-dev which might collect all those packages which are relevant to package multimedia applications (for sure there could be also more fine grained tasks for development issues created). In general I would strongly suggest: Please check out the tasks pages whether they are featuring your package and if not at least drop me a note to what tasks it should be added. Well, I think defining these tasks is not easy at all. AFAIUI, the user is expected to select a task and then *all* packages included in the task is going to be installed. However, in our multimedia land, we have both 'consumer' multimedia libraries like codecs, drivers, media players, and software for multimedia producers. For both areas, we have several similar software package that users most likely want to select alternatively, very seldomly together. The 'best' selection of packages depend of course on the exact requirements of the user, but most likely, it will not be the full set of available packages. Andreas, can you perhaps elaborate on your(?) / the idea about these tasks files and where are they maintained in Debian? The tasksel package or somewhere more decentrally? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
