Re: [Synaptic-devel] Build-Error on SuSE 9.1 i386

[Panu Matilainen]

On Fri, 18 Jun 2004, Michael Vogt wrote:

> On Fri, Jun 18, 2004 at 10:27:55AM +0300, Panu Matilainen wrote:
> > On Thu, 17 Jun 2004, Sebastian Heinlein wrote:
> > > Am Mo, den 14.06.2004 um 12:07 Uhr +0200 schrieb Michael Vogt:
> > > > On Mon, Jun 14, 2004 at 09:19:28AM +0200, Sebastian Heinlein wrote:
> [..]
> > As for task-packages .. they kinda suck :-/ IIRC Debian no longer uses 
> > them but something called "tasksel" 
> 
> Yeah, task support for synaptic in debian is broken since tasksel came

Ok.

> around. Tasksel works pretty interessting. It calls "apt-cache
> dumpavail" and read the "Task: taskname" tag that some packages
> have. Then it reads /usr/share/tasksel/debian-tasks.desc for a
> description of the tasks. If then just calls:
> system("apt-get install package1 package2 ...")

Right .. I had a quick look at tasksel myself (just remembered that I have 
woody installed inside vmware :) - if tasksel would give some way of 
listing the packages in a given task and couple of other options it'd be a 
perfectly usable backend for the groupinstall stuff as well. Alas it 
doesn't but making a script to do that wouldn't be hard at all.

> 
> > and I've been using a comps.xml 
> > (RH-thingy) based solution using Lua-scripts which looks like this:
> [..]
> > address@hidden pmatilai]# apt-get groupinstall sql-server
> [..] 
> > The names are parsed from comps.xml which holds the group names and their 
> > contents and only the contents are installed, no empty metapackages 
> > involved. Works very nicely but there's no way currently to hook that with 
> > Synaptic :( 
> 
> Yeah, I read about this one when I tried to find some good arguments
> why debian apt could make good use of lua too (it does not include lua
> now). I like the groupinstall stuff and lua :) 

Yep, the lua-interface is an incredibly powerful feature. I find it hard
to understand that debian isn't including it because of ABI breakage
(like, how many applications would that break that couldn't just be
rebuilt - doubt there are any). I guess one needs to see the lua-stuff in 
action to "see the light" :)

> 
> > Does tasksel on Debian somehow hook up into Synaptic, or in other words,
> > do the tasksel tasks show up in Synaptic on Debian? Any pointers to how
> > that works would be appreciated... as would ideas/discussion how to make
> > it possible to hook my lua-comps.xml system into Synaptic for that matter
> > :)
> 
> Synaptic does not integrate with tasksel right now. This is something
> I really want to change. The problem is that I want to present the
> tasks to the user in a nice graphical way. Debian uses a task system
> with two levels right now. There is a general topic like "End-User",
> "Hardware Support", "Servers" and for each of this topics there are
> the actual tasks (Hardware Support/Laptop, Servers/DNS server). 
> 
> Now I thought about making the tasks virtual packages for synaptic
> again. So that you install, remove upgrade a task just like a normal
> package. The are grouped by there "topic" and under a new option
> "tasks" in the optionmenu. Mockup:
> 
> +--------+
> |Synaptic|
> +---------------------------------------+
> |  tasks  V|S| Name       | Version | ..|
> +----------+-+------------+-------------+
> | ALL      |  Mail server             |
> | End-User |  Print server            |
> | Hardware |  DNS server                |
> | Servers  |  File server             |
> +----------+----------------------------+
> 
> This is a pretty big efford as it means to write a abstract
> "BasicPackage" calls that is the Parent of "Package" and
> "TaskPackage". We have to touch quite a bit of core code to do this. I
> actually have a proof-of-concept patch for this.
> 
> But we would need to write a backend in C++ for each tasksystem we
> want to support (debian, RH, does suse have one too?) and we won't be
> able to reuse your code. And it may be difficult to map a "flat" task
> hirachy into this two panes design.

Ouch .. that hurts. For the comps.xml format we'd need to parse a 
relatively complex xml file which I'm not looking forward to do (there's a 
python parser included in RHL/FC to parse that for you into nicely 
digestible format so the effort to use that is practically nil) and .. 
just how many such formats there are in general: Suse has their own .sel 
files (which is a straightforward tagged ascii file), dunno about 
Conectiva and others.

> 
> While writing all this, I think we can go with a simpler solution. We
> add a new option "tasks" in the men. It opens a modal window that
> displays a list of tasks. If you double-click on one, all package
> names in the task are set to "install". To make portability easy, we
> could add hooks so that a script can be plugged in that provides the
> names of the available tasks and returns all packages that belong to a
> given tasks.
> 
> What do you think?

I was thinking about something like that as well, and that's quite close 
to what my groupinstall thingy does right now: it has a separate backend 
script which provides three different operations, outputting to stdout:
showgroup <group(s)> (give a description of the group(s) and package list)
showgroups (list all available groups and their descriptions)
grouppkgs <group(s)> (list packages belonging to group(s))

The rest of the operations are completely independent of the underlying 
group metadata information so the backend is the only thing that needs to 
be written for a given group/task system.

So.. what you describe above maps in fact perfectly to this: 
1) User selects Tasks, synaptic does the equivalent of "showgroups" and 
presents the list in a modal windw (or would it be easily possible to 
populate the task-section with that info?)
2) User rightclicks on a group to get more info about the group/task (or 
click a "summary" button or whatever) -> synaptic does the equivalent of 
"showgroup <group>" and shows the info in a window
3) User selects the groups/tasks [s]he wants, synaptic queries the backend 
for the packages included in those groups and marks them for install or 
removal.

This way we could share the same backend script/code for both Synaptic and
a lua-enabled apt (wouldn't be hard to add the functionality to non-lua
apt either). Oh and I'll be happy to fix/tweak the current groupinstall
stuff so that it meets any additional requirements by Synaptic (output
format-wise or whatever) so that we can end up having a common system for
all of this (which would be superb cool).

        - Panu -