Packaging/Review Guidelines change

[Nicolas Mailhot]

On Lun 9 janvier 2006 17:14, Peter Jones wrote:
> On Mon, 2006-01-09 at 16:51 +0100, Nicolas Mailhot wrote:
>> On Lun 9 janvier 2006 16:16, Peter Jones wrote:
>> > On Mon, 2006-01-09 at 10:54 +0100, Nicolas Mailhot wrote:
>> >> On Lun 9 janvier 2006 05:51, Peter Jones wrote:
>> >> > On Sun, 2006-01-08 at 19:21 +0100, Nicolas Mailhot wrote:
>> >> >
>> >> >> Well, if Fedora is serious about this rule, should not Fedora's
>> rpm
>> >> be
>> >> >> patched to emit a warning when operating on a dir owned by
>> something
>> >> >> else ?
>> >> >
>> >> > rpm knows about packages, not repos.
>> >>
>> >> rpm knows about its db state when performing
>> >> installations/uninstallations.
>> >>
>> >> I meant a warning at rpm -U/-i or -e time not at rpmbuild time
>> >
>> > Then you're notifying the wrong people that something is wrong.
>>
>> Do you really believe it's not the user problem if its system is about
>> to
>> switch to a state where we know problem may happen ?
>
> I really don't think this ever hurts a user, it's just a matter of
> tidiness.  But more to the point, we can't restrict this sort of thing
> in other repos a user may be using, and we'll never be able to.  I don't
> like spending effort on something we really can't address in any
> meaningful way.
>
> It's a policy for the repo, about the repo, regarding how packages that
> are part of the repo should behave.  It is only a problem in the context
> of the repo.

Pure Fedora repo installs do not exist in real life. Even among FE
packagers. Even I'd wager on Seth systems. What matters is installed
systems. Everything else is mental masturbation no one sane should spend
time on.

>  The checking belongs in the relationship between a package>
> and the repo.  Nowhere else.

Repo checks by themselves have zero zip nill interest if they do not
translate to real system checks at some point in time.

>> >  If
>> > you're going to automagically probe for this and raise some
>> > error/warning/notification, it needs to happen when the package is
>> added
>> > to a repo.
>>
>> Sure
>>
>> > Before then it's incorrect,
>>
>> Why ?
>
> Because a single package can't conflict with itself in this way?  The
> entire notion of the problem only exists within the context of a repo.
> You can't tell that a package is violating the rule unless you know
> where the package is going.  Furthermore, the installed set of packages
> may not be a reliable source for what is and isn't going to be in the
> repo -- think about Obsoletes: .

You're building on a particular system for the same kind of system.
If the build system is not clean enough for your tastes, you can use mach.
There's so many ways the build system can influence the build result it's
not even fun pretending it's worth ignoring some part of it because the
install system will be "different"

>> > and after then it doesn't help to know it's busted.
>>
>> Of course it helps, do you really believe we catch every problem at the
>> packaging stage ?
>
> I really think we can throw an error when you try to add something
> broken to the repository.
>
>>  You could as well advocate removal of every single
>> warning/error in live systems, since problems should be fixed before
>> software is shipped (in an ideal lalala world)
>
> This would be a warning message that's only useful to developers.  As
> such, we should not be displaying it during installation, as it only
> serves to confuse most users.

Who will report it which will enable someone to fix it.
Either this is a real problem and it needs to be checked in real life (ie
on the live system), or it's not and worrying about this point is useless.

And the whole
if ! bugs_I_m_interested_in do_not_warn_user
is pretty disgusting if you want my opinion.

We're here to support users not the other way around. Warning/error
filtering should be based on user needs not Fedora packager needs. Users
do not care if a potential problem has its root in Fedora or another repo.
If the conflict if with a non-Fedora package it's perfectly ok to redirect
users to the packagers of this third-party package.

And that's assuming rpm will only catch errors with third-party packages.
I'm far from confident the FE review process won't let some mistakes pass
through

And third party repos also means all the repos which eventually merge with
Fedora (people.redhat.com repos, jpackage, etc) so letting packages rot
there when we could have them fixed as soon as a problem is introduced is
no t particularly productive.

-- 
Nicolas Mailhot