Re: Bug#543969: [P-a-s]: Please make checkpolicy libselinux libsemanage libsepol policycoreutils sepolgen setools plicycoreutils Linux specific
On Thu, Aug 27 2009, Cyril Brulebois wrote:
> Manoj Srivastava <firstname.lastname@example.org> (27/08/2009):
>> > It's so *nice* to see that after gathering advice from so many
>> > channels you still manage not to put the -bsd list in copy. :)
>> I am not sure why you think the bsd list should have been
>> copied. I did not copy the hurd list either. The fact that the SELinux
>> packages are linux specific is no surprise, and recordi g that in P-a-s
>> just corrects an oversight on my part.
> Because after having asked on #dd and #-kbsd the same questions (you
> were asking the proper thing to do, etc.), you were answered to please
> Cc -bsd@ to make sure everything was in order, which you didn't do.
> Of course, trying to get opinions on IRC, being explicitly told not to
> rely on IRC, and to use mail instead is something you may want not to
While I do ask for opinions, the final decision about my
packages, as well as the final responsibility, remains mine. I am
sorry if I gave the impressuon that I was looking for orders, or that I
consider doing everrything some one tells me to do on IRC.
i do appreciate your input about this issue on IRC. I listened
to it, factored in other things, and decided on course of action as I
> follow in the end… [*]
>> > Thanks for being so nice to porters after having tried so hard to
>> > understand the picture!
>> I did not think this is a matter of porting -- indeed, porting
>> SELinux is probably onerous enough to be impractical. The solution for
>> squeeze is not to build these packages for !Linux, and the earlier we
>> get started removing them and rolling out new versions of packages that
>> link to the libraries the better. It is not as if the old packages are
>> gone, so there is no forced timeline.
> From the libsepol1 bug, you might infer that porters care. And guess
> what, porting is not about porting everything. It's about getting an
> architecture together. That obviously (or is that not so obvious?)
> includes dealing with packages that are arch-specific. That means
> P-a-s. Surprise!
Right. And as package maintainr, it is also my duty to advice
the P-a-s maintainers when my packages are arch specific, and when some
architectures are not supported. I had been remiss here, and I have
belatedly correced that. Unless you are asserting that ony porters may
ask for changes, which I disagree with, I do not see reason for your
>> > Time for me to go back sucking my eggs, see you later!
>> From this I infer you are annoyed. I acknowledge that, though i
>> fail to see why exactlty.
> See [*] above. If you want to do something your way, don't ask for
> opinions and ignore them afterwards. And play the “I don't know what
> you mean” guy. That's just grotesque.
These are not exclusive. I do intend to ask for advice, and
still make my own decision. I am sorry if ou got the impression that
asking for advice meant ceding decision authority over my
package. One gets all kinds of advice over the net. Critical thinking
and making up one's own mind is still advisable.
Learning without thought is labor lost; thought without learning is
perilous. -- Confucius
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C