[csw-maintainers] Aliased names vs dummy packages [Was [csw-pkgsubmissions] newpkgs py_webpy]

[Ben Walton]

Moving this existing discussion to maintainers@ so people not
following pkgsubmissions can chime in...

--- Begin forwarded message from Philip Brown ---
From: Philip Brown <phil at bolthole.com>
To: pkgsubmissions <pkgsubmissions at lists.opencsw.org>
Date: Mon, 24 Jan 2011 09:14:49 -0500
Subject: Re: [csw-pkgsubmissions] newpkgs py_webpy

On Sun, Jan 23, 2011 at 8:09 PM, Philip Brown <phil at bolthole.com> wrote:
> On Sun, Jan 23, 2011 at 8:04 PM, Ben Walton <bwalton at opencsw.org> wrote:
>...
>> My point here is that if you want both naming consistency (good) and
>> installation by friendly name (also good), you can have that by
>> packaging under the standardized format and providing stub packages
>> with the friendly name.  I don't see a problem with stub packages but
>> I do see a gain from using them where appropriate.  To my eye, this is
>> an appropriate use.
>
>
> Mmmm... but from my perspective, having a view of the entire system
> from all layers, it feels... wrong.
> Might almost be better to support some kind of proper 'aliases'
> mechanism for the catalog instead. dunno.
> Needs to be pondered on.


well, I've slept a bit, and pondered a bit, and I'm liking the package
idea a bit better than mucking with the catalog format.
In its own way, a virtual package can serve well as an "alias in the catalog"
To articulate the "wrongness", the following are my areas of concern with it:

1. having it registered in mantis. I'm thinking it would be nice to
NOT register it
2. having another file almost needlessly sitting in our archives
3. having a "fake package" being actually installed on the user side
when thats not what they really need

#2, I think I might just have to live with

#1, perhaps if it is agreed we dont want to register it, we can come
up with some kind of agreed naming/pkginfo trigger that says "do not
autoregister", this is just an alias

#3... I'm thinking we might write it to deliberately NOT install. a
very elegant solution, in a way: it would still pull in dependencies,
but yet not needlessly install itself
  Only problem with that is, it would then potentially stop
pkg-get/pkgutil from proceeding further.
  This MIGHT be seen as a good thing; it alerts the user "hey you did
something you shouldnt really be doing".
  On the other hand, this would stop  "pkg-get install all" from working

  ... Unless we updated pkg-get and pkgutil to also recognise the same
magic for #1, and not fuss if that package bombed. Or, just not really
pkgadd in the first place. Well, maybe we should still do that, so
that the package gets to put out a special message? Dunno, there's a
few ways we could go, there.

This probably deserves a fresh thread in maintainers, if you're really
serious about it.
--- End forwarded message ---
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302