Re: debtags support proposed for xcontrol
On Fri, 11 Apr 2008, Jonas Smedegaard wrote:
[ ... long arguing cropped ... ]
Jonas, unfortunately I'm afraid I don't understand what you are talking
about. The only chance I see to understand is that you try to analyse
in how far cdd-dev works wrong and provide a patch that fixes the problem.
I just fail to see your problem but I happily accept anything that solves
your problem and results in the same meta packages as we have now.
I don't get it. Do you say that the control file does or does not
change based on changelog file?
If you say "make dist" debian/control might change. The target distribution
that is mentioned in the changelog file might be one method to influence
the change.
...even on build daemons, or what triggers an update?
Build daemons don't say "make dist" and so there will be no change
in debian/control (which is required by policy and this is what I
continuosely said: the main goal of cdd-dev 0.5 was to build meta
packages compliant to policy). Did you tried a build on your side?
Did debian/control change? If you would have done the answer would
be obvious.
Your "make dist" does the equivalent of these autotools commands:
autoreconf
configure && make dist
make maintainer-clean
That is a very unusual "make dist" routine IMO. Don't you agree?
If I would think so I wouldn't have implemented it this way. If you
know a better solution just implement it. I'm not very proud on the
solution - but ist works for now and does not violate policy.
Would you be interested in cleaning that up, or was that on purpose?
The purpose was to get something working. I would change it if
something stops working. I would be more than happy if somebody would
provide something that is _working_ *and* _nice_ .
You obviosely never inspected the released tarball.
I sure did. Your debian/control target is declared as .PHONY, and
debian.control file is indeed touched at build time.
Hups? YOu got a diff or a changed timestamp???? Strange!
I have not fully understood the inner workings of cdd-gen-control but it
seems invoked always, also on build daemons. That worries me.
$ grep gen-control debian-edu_0.828_i386.build | wc -l
0
$ grep gen-control debian-med_0.18_i386.build | wc -l
0
WHAT worries you????
Oh, and you have a typo in there: s/lover/lower/
What where? In the SVN? What about fixing it?
If what you say is that you only want to discuss further if I can
demonstrate a situation that actually causes Policy violation, then fair
enough - then I shall not waste your time any longer... :-/
You are actually not wasting my time, but I just can't get your problem?
So may be I can understand it by seeing the code you prefer.
And I am offering a solution - if only we can agree what is the problem.
You are offering a solution to a problem that is unknown to me?
Fine I like solved problems. Really! (There is no irony in it.)
Just go for it.
This is not true. The build system was not broken at all. Holger
_thought_ it would be broken but it was perfectly fine. What was
broken was _another_ _external_ tool that was not able to cope with
a feature that Holger introduced into the changelog. If you would
have tried to build the tarball using "make dist" this would have
been failed which is perfectly correct behaviour because if there
is no target distribution specified no tarball should / can be
released, because no dependencies can be resolved for the distribution
"UNRELEASED".
I don't care who or what wrote UNRELEASED into the changelog, or who or
what chose to build the package while in that state.
Well, one last try to explain what happened with this UNRELEASED issue.
Assume you have a copy of MS Word. Assume you have tried to open
debian/changelog of the cdd package. This might have triggered a
bug. Would you have blamed cdd-dev for this problem? I hope not.
So if you use debian/changelog with other tools outside of Debian
that are not under our control, please do not blame cdd-dev for this.
This is just unfair. There might be other problems in cdd-dev, but
this is no issue I can care about (and I even have given a hint on
the Debian-Edu list how they can elegantly solve the problem on their
side).
But I do care
where is this distribution field limitation?
* Debian Policy?
* Some unnamed other external debian edu specific tool?
* cdd-dev?
I suspect cdd-dev - wich is _exactly_ my concern here.
Your suspicion about the case above is wrong and I'm bored to
explain this. It might be that cdd-dev has a problem, but the
problem is definitely not that external tools fail to interpret
the changelog correctly.
No. I mean that I want it easy for others to throw the source package
into their automated build daemon, which might automatically change both
version number, distribution and other fields in the changelog, but
STILL the package should preserve the old control file!
See above. You obviosely never tried or you are using something else
than cdd-dev 0.5.0. Please prove by a build file or a diff or whatever
but don't force me to answer over and over guessings about how
cdd-dev might work.
I try to explain to you that I dislike being forced to dig into the
inner workings of a package in order to backport it.
???
What?
This is all handled by dpkg-buildpackage. Why on earth o you want to
reimplement those core tools?
Uhmm, I'm giving up. What on earth is reinvented in cdd-dev???
If empty tarball is a problem, then throw in a COPYING and a README,
just for the fun of it.
dpkg-* automagically generates a diff. Or do you mean something else?
Yes. I defintely mean something else, but I obviosely fail to descibe
it several times and I feel tired to do so now and my boss would fire
me if I would continue to spend my working hours in explaining stuff that
has nothing to do with my task here. So because I'm de facto offline
over this weekend I advise you to read and test the code. I never
liked to say this but I have no other chance. Sorry for that. I
don't intend to offend you by this rude request - but I have simply
no time for further elaboration on this.
Here's a recipe for changing to cdbs-style update of control file:
1. Drop "make dist" - attach it to "make clean" instead, wrapped in
an ifdef so it is only ever invoked when
DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes
3. Rewrite to always update (not only when controlfile is missing)
That's it.
Go for it! You have SVN access.
The hard part (it seems) is for you to understand how it works... :-P
Obviousely. Yust show me the code that makes it working.
As I understand it, you have consistently claimed that current approach
works fine and that you cannot see any need to change, but now suddently
you _do_ agree that non-native packaging is better,
Sorry that I have seen some point in YOUR arguing. You seemed to have
caused some fluoresce on the end of my tunnel of darkness. But if
you are not happy about the fact that I see some point in your words
I'm happy to claim that I was perfectly right? (Jonas, can you feel
that I start to become mad? ;-)))
or do you somehow
argue that non-native packaging won't work with Skolelinux?!?
I fail to see the relation to Skolelinux in all this. You requestet
non-native packaging. I did not. After hours of reading long mails
I have admitted a small point in your arguing - not yet convinced that
it would make any real difference. What are you talking about????
This final OK seems like my interpretation inside the my last
paragraph was basically right.
No, I do not agree that it is extra work for no profit at all.
OK, so _I_ see no profit and so _I_ will not work on it. Is this OK
for you?
I am very confused if you are at all interested in this correspondence.
I do answer only to mails I'm interested in.
I Feel like we are going in circles here :-(
Yes we do. In the beginning you promised a solution. Where is
the code that provides a solution?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: