On Tue, 08 Jan 2019 00:37:05 +0000, Dominic Hargreaves wrote:
> > > There are two modifications that could be made to the logic for
> > > constructing depends relating to dual lived modules:
> > >
> > > 1) remove the alternate depends on perl when a versioned dep is needed
> > > 2) always depend on the virtual package name, regardless of whether a
> > > version is needed
> > >
> > > 2) is appealing because it removes the special casing completely, but
> > > would probably make quite a few fields longer. Maybe with automated
> > > tooling this is okay, though.
> >
> > I'm afraid I still don't understand the options, or more exactly
> > option 2.
> > Option 1 is, I guess, Niko's example from above.
>
> Yes, option 1 is for versioned deps on dual lived modules to drop
> the perl alternative.
Ok.
> > Would option 2 then
> > be just 'libfoo-bar-perl'? If so I'd say yes, that was the idea IMO
> > (unless Foo::Bar is included in the oldest perl version in the
> > archive). How would this make "a few fields longer"?
>
> Not quite. My phrasing was a bit unclear, but I meant that we'd have
> all dual lived module dependencies declared in debian/control
> even though they are already satisfied by a dependency on perl.
Ah, I see.
> That would increase the size of the dependencies on almost every
> module package, but would remove the need for any special casing
> in tools constructing Depends lines programmatically, including
> for changes over the lifecycle of the package because, for example,
> a module is added or removed from the dual lived packages list.
Ok, that would have saved us from adding libmodule-build-perl to
dozens (hundreds?) of packages, when Module::Build was removed from
core.
> In my proposal 2), looking at META.json:
> "runtime" : {
> "requires" : {
> "Carp" : "0",
> "DBD::SQLite" : "1.54",
> "DBI" : "1.627",
> "File::Spec::Functions" : "0",
> "File::Temp" : "0",
> "Mojolicious" : "7.32",
> "SQL::Abstract" : "1.81",
> "Scalar::Util" : "0",
> "URI" : "1.69",
> "URI::db" : "0.15",
> "URI::file" : "4.21",
> "perl" : "5.010001"
> }
> ...
>
> we'd also add
> libfile-temp-perl and libscalar-list-utils-perl to the list
> (having previously added Provides for all of the dual lived modules
> in the perl distribution).
Hm, interesting. And in a way attractive.
That would e.g. we'd have to add libtest-simple-perl to about all
packages …
Bringing our dependencies closer to META.* also sounds nice; but this
will still be no 1:1 mapping if we "only" take dual-lifed modules. In
the example about Carp and File::Spec::Functions are still
unaccounted for, unless src:perl starts to Provide virtual packages
for all the included modules …
So, yeah, I'm not sure :)
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Bruce Springsteen & The E Street Band: Atlantic City
Attachment:
signature.asc
Description: Digital Signature