Re: debtags support proposed for xcontrol
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Apr 07, 2008 at 08:26:54AM +0200, Andreas Tille wrote:
> On Sun, 6 Apr 2008, Jonas Smedegaard wrote:
>> Due to CDD metapackage package dependency lists currently being
>> maintained by hand, they tend to only infrequently be updated.
>
> Uhmmmm, I don't agree with this sentence. ;-)
Sorry.
s/tend to/might/
> We have means to include even not yet available packages (we call it
> "Prospective Packages" [1] and so we are prepeared evn before the
> package shows up in Debian. Once it is there it becomes automatically
> included in the list of Dependencies in the control file after package
> rebuild. At least we in the Debian-Med team make heavy use of it
> because I watch WNPP closely and include any relevant WNPP just in
> time.
Indeed.
And the support for local debtags data should support situations like
that. I have not yet figured out the details of that, however, as there
are multiple situations:
* Debtags additions (for hinting not-yet-even-packaged software)
* Debtags overrides (for hiding or fixing/distorting official hints)
I have not played with actual debtags databases for ages. I remember a
diff-like mechanism to store also overrides, and intend to use that
data format for inclusion within source packages.
This has the added benefit of being relatively easy for Debtags
maintainers (or anyone else) to then collect themselves at a later point
- - similar to how lintian maintainers can learn from looking at lintian
overrides.
>> a) Always regenerate but fail build if control file content change
>> b) Only regenerate when some environment flag is set
>
> Perhaps as we do it in cdd-dev:
>
> c) Generate debian/control inside get-orig-source target
> of debian/rules and have no debian/control file at all
> before. You just build the source tarball and once
> it got the debian/control file start building the
> package using pdebuild (or something like that)
From the viewpoint of Debian official build routines, I see b) and c) as
equal:
b) Only (re)generate when asked to do so explicitly
Updating stuff below the debian dir in the get-orig-source target seems
wrong to me: I would expect that target to only deal with, well,
getting the original source as a compressed tarball.
But that is just my personal interpretation. If anyone knows of some
(semi-)official definition for the use of the "get-orig-source" and
"print-version" build targets. I have a draft implementations of a cdbs
snippet implementing those targets in a generic way, and obviously want
it to follow current trend. :-)
Do you use get-orig-source in some automated routines? Then I would be
interested in understanding those too - for the same reason.
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH+jKcn7DbMsAkQLgRAtNuAJ9/2G5Ug9Y6ZneX2wETMckbGaI8mQCfawob
+7zUXksMNrubJrkfMNAQxl8=
=/MjF
-----END PGP SIGNATURE-----
Reply to: