Strawman problems or poorly done homework? [LWN.net]

Strawman problems or poorly done homework?

Posted Jul 29, 2004 8:28 UTC (Thu) by angdraug (subscriber, #7487)
Parent article: OLS: An introduction to Conary

Repositories are an afterthought.

Debian pools are definitely not an afterthought. It is elegant, effective, and extensible solution. What's wrong with it?

The version scheme used by most package managers follows a straight line model; there is no provision for branches.

I don't see any advantage in cramping all the versioning, branching, and tagging information into a package version, as opposed to managing this separately. I like Monotone's idea of using SHA1 for a version: if the file is the same, its version should be the same no matter in how many branches it is available.

Packages contain scripts which handle parts of the installation and removal process which go beyond the simple management of files.

At a certain level of complexity, some things are better done as scripts, as opposed to declarative programming. Either you try to provide a better scripting environment to solve these tasks, or you go the route of XSLT.

(Log in to post comments)

Strawman problems or poorly done homework?

Posted Jul 29, 2004 15:54 UTC (Thu) by vmole (guest, #111) [Link]

Debian pools are definitely not an afterthought.

Debian pools are absolutely an afterthought. The fact that they are a really good solution to the problem doesn't change that. We lived for years with seperate trees for each release.

The entire Conary article reads like someone is trying to solve the random RPM problem, where "repositories" are simply piles-of-files, and has never seen the Debian solution. I know that's not true, so my guess is it's a way of making Specifix look like they've solved more problems than they have. This is unfortunate, because based on the article, they are solving problems that the Debian system doesn't.

I do agree with the previous that leaving the dependency problem for "later" is likely to be a really bad idea. But the RPM developers have never given the problem the respect it deserves, much to the pain of their users.

Triggers in dpkg/APT?

Posted Jul 30, 2004 1:15 UTC (Fri) by AnswerGuy (guest, #1256) [Link]

One think I'm curious about. Is there support in the Debian packaging system for triggers (like RPM has)?

Triggers don't seem to be widely used (packager ignorance?) but they seem like a neat idea. With some carefully designed standards among packages
they could make your package management system almost "object-oriented."

(Consider: you install a mail user agent (MUA) which registers a trigger on the virtual package MTA. When any MTA is installed, the trigger runs a script which invokes the MTA's own MUA registration script. Now all MUAs can have some setting adjusted when an MTA is replaced. All of the MUAs "know" whether the system is using mbox, maildir, or MMDF system mailboxes --- for example).

(Sorry if the example is silly --- better examples might relate to registration of menu items and icons in window managers or something).

JimD

Triggers in dpkg/APT?

Posted Jul 30, 2004 13:08 UTC (Fri) by frodonl (subscriber, #16826) [Link]

While I don't know about any triggers functionality in the Debian packaging system - I never needed them, so I never really searched for it, Debian does define a standard way to create menu items, called the Debian Menu System.

It works by postinstall and postrm scripts calling one central command (update-menus) that will call the menu-update scripts for the various packages that use "menu managers".

Grtz,

Frodo

Triggers in dpkg/APT?

Posted Aug 3, 2004 16:43 UTC (Tue) by angdraug (subscriber, #7487) [Link]

Assessment of triggers is the one thing in the Conary whitepaper that I tend to agree with. Triggers require that too many packages know too much about each other: this creates more complexity and points of breakage than it's worth. Think of it as dependency hell on drugs.