[csw-pkgsubmissions] newpkgs libffi5, libffi_dev, libffi_stub

[Philip Brown]

2011/5/3 Maciej Bliziński <maciej at opencsw.org>:
> 2011/5/3 Philip Brown <phil at bolthole.com>:
>>>  In a typical case, we have:
>>>
>>
>> I think you overstated that case. It may be better to write it up in
>> the style that were are commonly using it for:
>>
>> libfoo1 is taking the place of plain libfoo, and CSWlibfoo is a
>> required dependency.
>
> Before we get further, I need to make sure that I understand what you
> mean.  If you say that libfoo1 is taking place of libfoo, it isn't
> enough, because there are certain steps to be taken for that to be
> handled properly.  If I understand correctly, we start with a single
> CSWlibfoo/libfoo package and at the end of the process we have 2 (and
> only 2) packages: CSWlibfoo1/libfoo1 + CSWlibfoo-dev/libfoo-dev.

yes.

>   If
> you unpack the notion of "taking place", what exact steps does that
> involve until the final state? (let's assume that CSWlibfoo has both
> dependencies and dependent packages)

Okay, so to be explicit, I'm guesing you mean the case where there is
no backwards compat lib being delivered.
I did give an overiew, but I guess you want way-down-individual-step
happenings. Ok.
I will comment on dev at end.

Initial on-system deployment state:
CSWlibfoo  (contains libfoo.so.1)
CSWappfoo, depends on CSWlibfoo, libfoo.so.1
CSWappfoobar, depends on CSWlibfoo, libfoo.so.1

Initial user/sysadmin action:
 pkg-get upgrade (all)
There are a couple of potential states in the catalog that could be in
existance here:
a) new replacement for libfoo only (CSWlibfoo1)
b) new replacement for libfoo, AND a new upgrade for appfoo, or some
other app that uses it.

If there is no stub.. then I confess, for case (a), nothing will
happen, unless the user explicitly asks for the new libfoo1.
If they do, then CSWlibfoo1 is downloaded. It conflicts with
CSWlibfoo, so that is auto-removed.
Then new CSWlibfoo1 is installed, which provides the required runtime
libfoo.so.1 that appfoo and appfoobar need.
Old obsolete CSWlibfoo is no longer present on system
 Packages now installed on System:
  CSWlibfoo1 (contains libfoo.so.1)
  (old)CSWappfoo, depends on CSWlibfoo, libfoo.so.1
  (old)CSWappfoobar, depends on CSWlibfoo, libfoo.so.1

For case b:
 new release of CSWappfoo is available, that has an updated dependancy
pointing to CSWlibfoo1.
 installation of CSWappfoo pulls in the libfoo1. Things proceed as in
case(a), above. Then newer CSWappfoo is installed.

 At this point, appfoo happily runs, and appfoobar also runs.
 Old obsolete CSWlibfoo is no longer present on system

 Packages now installed on System:
  CSWlibfoo1 (contains libfoo.so.1)
  (new)CSWappfoo, depends on CSWlibfoo1, libfoo.so.1
  (old)CSWappfoobar, depends on CSWlibfoo, libfoo.so.1


Now to reply to your _dev case:
yes, if the OpenCSW side change, is a library split, AND a split out
of _dev files, then this is not so appropriate, in the sense that
development files get removed from the user machine side, and are not
automatically replaced.
That makes a case for _stub being used.
On the flip side, removing _dev related packages, does not really
*break* anything(in that it does not actually stop apps from running,
in the way that shared libraries do), so it isnt exactly what I would
call a "priority 1 bug".

In this case, I wouldnt complain if someone submitted a stub to pull
in the upgraded dev automaticaly. But nor would I complain, if they
chose NOT to do that.

All that being said.. my comments are for the narrow area of, "we're
just doing a shared lib split-off. nothing else is changing".

the devel->dev renaming, is another beast. It's rather gross. only way
to handle that in "automated" fashion that I am seeing, would seem to
be to keep using the stubs. Which is the other reason I was against
the renaming. it causes massive creation and use of over a hundred
stub packages. Ugh.