Re: [pkg-discuss] Design for "manual file dependencies"
On 11/21/11 15:54, Danek Duvall wrote: Brock Pytlik wrote: Do we need to allow users to specify path and basenames separately (like generate does) or is allowing multiple full paths sufficient? Can target be a relative path to source? Do you have a use case for either? The use case for the former is mostly less typing in some situations. Right. What kind of situation? I was specifically not thinking about the python module situation as I don't, yet, have a good solution for that one. The cases I was thinking about was when one library might be located in several locations. The difference would be whether the base name would be repeated once per directory. Alternatively, if two libraries could satisfy the dependency and lived in the same directory, then it wouldn't be necessary to specify that directory multiple times. I think it might also be worth thinking about the other pkgdepend abstraction bug we have, where we have to specify the full path in bypass-generate, rather than the high-level object that we want to ignore. This comes up when trying to bypass generation of dependencies on python modules, for instance -- you have to specify all possible paths of the python module, which is insane, or use a regular expression which is potentially far too inclusive. So, similarly, what if I want to declare a dependency on a python module? Why should I have to specify the full path(s) instead of just the module name (is this where you were thinking it would be useful to use a path and multiple filenames)? Fundamentally, we want to name the interface we depend on, which may very well be something other than a path or a service. So perhaps we need "kind" after all? (I'd probably use "target-type".) Or just like we have svc:/ (and potentially file:/) we could have python:/ which meant this thing I'm naming is a python module. Alternatively, we could have target-type and source-type and let those default to file. I think a similar approach holds for bypass-generate. We could have bypass-generate-type=python, or we could have bypass-generate=python:/... (and I guess in the same vein actually, we could have basename:/ and path:/ if we really need to meet that need. Danek and I talked offline and agreed that while the case for multiple targets of different types in the pkgdep space is limited, it seems reasonable to say "Skip both this python module and this service when analyzing the dependencies of this file." For that reason, we're going to go with the encoding within the token of source/target/bypass-generate. Brock Danek ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Design for "manual file dependencies"
Brock Pytlik wrote: > >>Do we need to allow users to specify path and basenames separately > >>(like generate does) or is allowing multiple full paths sufficient? > >>Can target be a relative path to source? > >Do you have a use case for either? > > The use case for the former is mostly less typing in some situations. Right. What kind of situation? I think it might also be worth thinking about the other pkgdepend abstraction bug we have, where we have to specify the full path in bypass-generate, rather than the high-level object that we want to ignore. This comes up when trying to bypass generation of dependencies on python modules, for instance -- you have to specify all possible paths of the python module, which is insane, or use a regular expression which is potentially far too inclusive. So, similarly, what if I want to declare a dependency on a python module? Why should I have to specify the full path(s) instead of just the module name (is this where you were thinking it would be useful to use a path and multiple filenames)? Fundamentally, we want to name the interface we depend on, which may very well be something other than a path or a service. So perhaps we need "kind" after all? (I'd probably use "target-type".) Danek ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Design for "manual file dependencies"
On 11/21/11 15:03, Danek Duvall wrote: Brock Pytlik wrote: * source - This contains the file or service which needs the target. (This is equivalent to pkg.debug.depend.reason in generated dependencies.) This can be specified more than once. Each file or service provided must be delivered in the same manifest as the dependency. I'd rather not require source or reason attributes -- I think it raises the barrier to using this construct sufficiently that either people will put in useless data (reason="because I said so") or they simply won't use it, which I think would be sad. I do think it'd be appropriate to have pkglint support for enforcing the use of it, though, so we can make sure that folks contributing to Solaris consolidations do use it properly (with code reviewers and RTI advocates making sure that silly reasons aren't used). Ok, I can buy that. Should we keep kind, or should target and source just use schemes to identify the kind of thing they're referencing? I'd lean towards merging kind and target and simply requiring a full FMRI and assuming a file path if there's no scheme. Sounds reasonable. Do we need to allow users to specify path and basenames separately (like generate does) or is allowing multiple full paths sufficient? Can target be a relative path to source? Do you have a use case for either? The use case for the former is mostly less typing in some situations. I don't particularly have one for the later, but it was something that came up when Tim and I were discussing that we didn't have a clear feeling on. Brock Danek ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Design for "manual file dependencies"
Brock Pytlik wrote: > * source - This contains the file or service which needs the target. > (This is equivalent to pkg.debug.depend.reason in generated > dependencies.) This can be specified more than once. Each file or service > provided must be delivered in the same manifest as the dependency. I'd rather not require source or reason attributes -- I think it raises the barrier to using this construct sufficiently that either people will put in useless data (reason="because I said so") or they simply won't use it, which I think would be sad. I do think it'd be appropriate to have pkglint support for enforcing the use of it, though, so we can make sure that folks contributing to Solaris consolidations do use it properly (with code reviewers and RTI advocates making sure that silly reasons aren't used). > Should we keep kind, or should target and source just use schemes to > identify the kind of thing they're referencing? I'd lean towards merging kind and target and simply requiring a full FMRI and assuming a file path if there's no scheme. > Do we need to allow users to specify path and basenames separately > (like generate does) or is allowing multiple full paths sufficient? > Can target be a relative path to source? Do you have a use case for either? Danek ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
