[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>:
>> that gets in the way of use of stub packages, I think.
>
> Is this libffi update a special case, or is it a later stage of a
> standard package transition process?


I think its a separate, but "standard" transition case, that the GAR
way does not yet handle.
"standard", in that it's quite likely to come up again elsewhere.3


>  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.


In contrast, the case we are dealing with now with libffi, is:

libfoo1 is taking the place of plain libfoo, and CSWlibfoo is NOT a
required dependency of anything.


In the former, the "stub" hackery, is useful only because the older
CSWpkg name is in use by other packages.


In the latter, the stub is not useful; our standard "replace, by means
of conflicts" mechanism does the job, and simpler is better. So, stub
should not be used in that case.


Please Note:

It could also be argued that even in the former case, the stub hackery
is only "useful", if there is a need to provide backward compatible
"libfoo0" packages/libraries for those legacy other packages.
If, in contrast, the other packages expecting CSWlibfoo, will function
correctly with a silent in-place upgrade of CSWlibfoo->CSWlibfoo1,
then the stub package is not really needed there either.
In that case, CSWlibfoo1 can declare conflict on CSWlibfoo, and it
will get removed; yet the
other packages will continue to function.
At such time that the other packages get upgraded, they will be
created with a depend on CSWlibfoo1
The old CSWlibfoo will never be missed.

This is why we didnt really need "stub" packages in the past. it was
mostly the invention of splitting up libraries into their own package,
and then retroactively attempting to supply "new" old-version library
packages, that drove it.

(that, and renaming nastiness. But again, if the dependency chain is
shallow or non-existance, I dont think stubs are needed)

Would be nice to avoid dumping *stub packages in our mirrors, when
they are not needed, rather than always blindly generating them.