[lsb-discuss] Packaging

[Michael Sweet]

Fabian Groffen wrote:
> On 26-10-2006 20:08:59 -0400, Michael Sweet wrote:
>> Fabian Groffen wrote:
>>> ...
>>> A package manager that can install into an arbitrary offset, such as [2]
>>> can of course easily handle the offset "/" for the host OS.
>> Given that we are talking about LSB packaging, RPM is the "standard"
>> package format, and any OS that doesn't use RPM natively will need to
>> support the RPM functionality/dependencies/etc.  It's great that
>> Gentoo can support it, but the important thing is that current RPM
>> supports it...
> 
> I see.  I was hoping for a more generic description of functionalities
> and requirements using *any* package manager to which we could comply
> to, and contribute in its specifications.  Since this is not the case,
> I'm out.  Sorry.  Thanks for your answer.

I'm not shutting out the generic discussion (and in fact, since I'm
not a LSB member, just another developer in this discussion, I have
no real "power" over the direction things go... :), I was just
saying that the LSB has already decided on RPM as a required format,
so that defines the "minimum requirements" for package installs.

Where we go from here is up to the LSB, presumably with input from
the likes of us... :)

So, to clarify my comment - I'm glad that Gentoo portage supports
offsets, and FWIW the Red Hat, Debian, Slackware, *BSD, AIX, HP-UX,
IRIX, Solaris, and Tru64 UNIX packaging systems all support offsets
or relocation as well.  My point is just that installing into an
alternate root is a well-supported feature that we know will work,
so we aren't "asking too much" in that respect.

I think the main issue now is defining how user installs interact
with system installs, and I'd love to hash that with you.

Dreaming about what functionality the actual packaging tools will
provide will also be fun and give others not privy to our discussions
our "big picture" of software packaging on Linux.  Those won't likely
be part of the actual LSB requirements - the LSB is concerned with
providing consistency for developers, not for distribution-specific
tools - but it *can* be part of an introduction/overview that gives
the reasons for the requirements, and of course we can have a Wiki
setup for collaboration between package manager developers so that
we get some cool stuff into our package managers!

OK, some questions for discussion, with my answers in-line:

1. Do we continue using the RPM format for user installs?

    Mike Sweet: I think so, the format supports relocation and it
    would be consistent for users - you either install as root for
    a system install or install as user for a user install.

2. Where do we put user installs?

    Mike Sweet: A subdirectory off the user's home directory, e.g.
    "~/.apps" or "~/.root".

3. How do user installs interact with system installs?

    Mike Sweet: User installs use a read-only snapshot of the system
    installs to do dependency checking.

4. How do system installs interact with user installs?

    Mike Sweet: System installs should ignore user installs. Let the
    user package management tools prompt the user when a system install
    replaces/upgrades a user install, and/or advanced system package
    management tools might give the admin a "big picture" look at user
    installs so they can install common packages, etc.

5. Do we want a standard package installation GUI?

    Mike Sweet: Yes, but I think the Portland project is the best place
    to define a command-line interface which starts the GUI.

Any other questions we want to answer, features we want to require,
etc?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com