On 05.12.2007 11:30, Patrice Dumas wrote:
> On Mon, Nov 26, 2007 at 05:18:19PM +0100, Thorsten Leemhuis wrote:
>> Sure it's dangerous and problematic -- but it's IMHO still way better
>> then to not ship a package just for hypothetical situation where a major
>> update might be the only way forward if a security issues comes up.
>> Besides: if we want to update for non-security reasons we can provide
>> compat packages as well, which should solve parts of the problem.
> Ok, but then what to do when a security issue is discovered in the
> package that is also relevant for the compat package but we don't want
> to backport it? Simply remove the compat package from the repo?

If there was a warning period or something like that, round about: yes.

Note that even RHEL does that iirc. Didn't they for example switch from
mozilla to seamonkey?

Cu
knurd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Wed, Dec 05, 2007 at 11:38:01AM +0100, Thorsten Leemhuis wrote:
>
>
> On 05.12.2007 11:30, Patrice Dumas wrote:
> > On Mon, Nov 26, 2007 at 05:18:19PM +0100, Thorsten Leemhuis wrote:
> >> Sure it's dangerous and problematic -- but it's IMHO still way better
> >> then to not ship a package just for hypothetical situation where a major
> >> update might be the only way forward if a security issues comes up.
> >> Besides: if we want to update for non-security reasons we can provide
> >> compat packages as well, which should solve parts of the problem.
> > Ok, but then what to do when a security issue is discovered in the
> > package that is also relevant for the compat package but we don't want
> > to backport it? Simply remove the compat package from the repo?
>
> If there was a warning period or something like that, round about: yes.
>
> Note that even RHEL does that iirc. Didn't they for example switch from
> mozilla to seamonkey?

But this is not exactly the same, since one obsolete the other. So the
plan could be along obsoleting th ecompat package with the oldest compat
package not having the security flaw? Otherwise the compat package will
stay happily even though it isn't anymore in the repo.

--
Pat

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On 05.12.2007 16:51, Patrice Dumas wrote:
> On Wed, Dec 05, 2007 at 11:38:01AM +0100, Thorsten Leemhuis wrote:
>>
>> On 05.12.2007 11:30, Patrice Dumas wrote:
>>> On Mon, Nov 26, 2007 at 05:18:19PM +0100, Thorsten Leemhuis wrote:
>>>> Sure it's dangerous and problematic -- but it's IMHO still way better
>>>> then to not ship a package just for hypothetical situation where a major
>>>> update might be the only way forward if a security issues comes up.
>>>> Besides: if we want to update for non-security reasons we can provide
>>>> compat packages as well, which should solve parts of the problem.
>>> Ok, but then what to do when a security issue is discovered in the
>>> package that is also relevant for the compat package but we don't want
>>> to backport it? Simply remove the compat package from the repo?
>> If there was a warning period or something like that, round about: yes.
>> Note that even RHEL does that iirc. Didn't they for example switch from
>> mozilla to seamonkey?
> But this is not exactly the same, since one obsolete the other.

Well, it was the same software in a newer version that also gotten a new
name.

> So the
> plan could be along obsoleting th ecompat package with the oldest compat
> package not having the security flaw? Otherwise the compat package will
> stay happily even though it isn't anymore in the repo.

Yeah, that could work.

But I think we just need to find individual solutions for problems when
we hit them.

CU
knurd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Wed, Dec 05, 2007 at 05:32:01PM +0100, Thorsten Leemhuis wrote:
> > So the
> > plan could be along obsoleting th ecompat package with the oldest compat
> > package not having the security flaw? Otherwise the compat package will
> > stay happily even though it isn't anymore in the repo.
>
> Yeah, that could work.
>
> But I think we just need to find individual solutions for problems when
> we hit them.

We need a little bit if planification too. If we bring a package in and
we find out that we cannot technicaly make the user notice that there is
something wrong with the package, it is a problem and we must take it
into account right now.

--
Pat

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On 05.12.2007 17:51, Patrice Dumas wrote:
> On Wed, Dec 05, 2007 at 05:32:01PM +0100, Thorsten Leemhuis wrote:
>>> So the
>>> plan could be along obsoleting th ecompat package with the oldest compat
>>> package not having the security flaw? Otherwise the compat package will
>>> stay happily even though it isn't anymore in the repo.
>> Yeah, that could work.
>> But I think we just need to find individual solutions for problems when
>> we hit them.
> We need a little bit if planification too.

Yes, completely agreed. But I'd like to avoid a deadlock where packages
do not enter the repo because people fear hypothetical problems. We'll
find solutions when problem comes up (just as RH sometimes has to find
special solutions). And nobody pays us for the job, so I suspect most
people won't yell at us when we say "okay, we had to update foo to
version bar which break ABI and API because backporting the security fix
was to hard"

CU
knurd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Wed, Dec 05, 2007 at 07:34:11PM +0100, Thorsten Leemhuis wrote:
>
> Yes, completely agreed. But I'd like to avoid a deadlock where packages
> do not enter the repo because people fear hypothetical problems. We'll
> find solutions when problem comes up (just as RH sometimes has to find
> special solutions).

I am not completly convinced, shouldn't the solution be found in fedora
rather than in EPEL?

> And nobody pays us for the job, so I suspect most
> people won't yell at us when we say "okay, we had to update foo to
> version bar which break ABI and API because backporting the security fix
> was to hard"

It is not the point, in my opinion. The point is if we can be almost sure
that a package will bring in some problems we want to avoid, then we
should avoid it. What is unclear to me is what we want to avoid.

--
Pat

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list