On 2017-05-06 08:38, Marco Atzeri wrote: > On 06/05/2017 02:20, Brian Inglis wrote: >> On 2017-05-01 13:57, Achim Gratz wrote: >>> Jon Turney writes: >>>> What is your reason for changing the name? >>> There shouldn't be two different naming conventions for the same >>> purpose. So >>> package-version-release[-purpose].tar.xz >>> with purpose:=[source|debuginfo] would be preferrable. >>>> I was wondering if we need to explicitly identify debuginfo >>>> archives as a different kind of thing. Currently, debuginfo >>>> packages work just like any other install archive, which is fine, >>>> except for perhaps they need a separate filter in setup. >>> They wouldn't with the above naming convention and you'd just tick >>> another box to say you want them installed, just like sources. We >>> might even skip the archful directories and just do >>> [noarch|x86|x86_64] as well in the same place. > Tick the box is already one of the least understood feature of setup, > I suggest to not add further stuff there. > debuginfo and src have a major difference in installation: > debuginfo are tracked as normal packages, reported on "/etc/setup/" > and they can be unistalled as any other package. > src package are not tracked at all and can not be unistalled with > setup. If we decide to manage them like the other packages we should > remove such anomaly.
The automatic/manual pick bit in installed.db could be extended to also add flag bits for installed -src, -doc, -devel, and -debuginfo pkgs, and it would also be useful to add flag bits for base pkgs and a sticky keep/hold bit to support that long requested feature. I've been looking at it from the perspective of adding apt-cyg features available in Debian apt{,-*}, without keeping info separate from setup which could become inconsistent. >> In the same vein, boxes for doc and devel packages, where >> available, would make selection easier for users, developers, and >> maintainers, but require changes to cygport and setup to integrate >> handling. > this is in IMHO a useless complication, the search filter is already > available for selecting similar packages. > We have multiple documentation or multiple development packages for a > single source package so clustering is not obvious at all For each binary arch install is there more than one each related -devel, -debuginfo, -doc, or -src pkg? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada