[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bootstrappable Debian - proposal of needed changes

On Wed, 2013-01-30 at 17:27:13 +0000, Wookey wrote:
> +++ Ian Jackson [2013-01-16 13:50 +0000]:
> >  * The concrete syntax in build-depends should not use < > but rather
> >    reuse the architecture qualification syntax.
> I have just been told of a specific reason to avoid using '< >' :
> DEP-11 proposes to use '< >' for Component metadata in binary packages 
> http://wiki.debian.org/DEP-11

I don't see any need to use <> for those, they would seem to only need
a delimiter character, something like «type;value» or «type@value», or
whatever else along those lines would work.

But, in any case, I don't think that proposal is a good idea as it
stands; dpkg does not support file depends, and we have always
considered that a feature. File depends have (at least) the following

* They bypass the normal shlibs/symbols dependencies, incurring in
  possible ABI issues.
* They do not play nice with Conflicted packages, as they only request
  a specific path, not a path supplying a specific interface. While
  we supposedly do not allow same paths for conflicting interfaces,
  that's just a Debian policy.
* By allowing that kind of extension in the Provides field, it implies
  we'd be accepting them in any dependency field.

In addition:

* Hardware IDs require patterns and similar, which TBH I don't think
  should be supported in dependency fields, and at least not sneaked
  in such a non-generic way.

Once the path based provides are removed the remaininig seem
representable quite fine with something like debtags. Otherwise if
this is supposed to only be used by PackageKit and debtags is really
not appropriate, then a new field might be fine too. But do not get
me wrong, I think that getting rid of the app-install-data is a worth
while goal, just probably not in that shape.

> Should this profile stuff be written up as a 'DEP'? 

Please, I'd rather we didn't?


Reply to: