FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-05-2010, 03:03 PM
Tom Lane
 
Default Our static Libraries packaging guidelines once more

Michael Schwendt <mschwendt@gmail.com> writes:
> How much do we adhere to our Packaging Guidelines for static libraries?
> https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

> Mispackaged -static libraries:
> mysql-devel from mysql-5.1.42-2.fc13.src.rpm
> postgresql-devel from postgresql-8.4.2-1.fc13.src.rpm

As far as these two go, I think it's just a matter of the specfiles
dating from years before we had any such guideline, and not revisiting
the point since then. I don't have any particular objection to removing
the static versions of their libraries. On the other hand, with the
guideline being so widely ignored, I'm not in a hurry to do work to
comply with it ...

regards, tom lane

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 03:30 PM
Jesse Keating
 
Default Our static Libraries packaging guidelines once more

On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote:
> On the other hand, with the
> guideline being so widely ignored, I'm not in a hurry to do work to
> comply with it ...

Isn't that a chicken/egg problem?

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 03:48 PM
"Tom "spot" Callaway"
 
Default Our static Libraries packaging guidelines once more

On 01/05/2010 11:30 AM, Jesse Keating wrote:
> On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote:
>> On the other hand, with the
>> guideline being so widely ignored, I'm not in a hurry to do work to
>> comply with it ...
>
> Isn't that a chicken/egg problem?

It really is. I mean, we could create the "Packaging Police" to run
around and enforce the guidelines by force (either by fixing them
manually, or by threatening maintainers until they do it), but is that
really what we want?

~spot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 04:08 PM
"Daniel P. Berrange"
 
Default Our static Libraries packaging guidelines once more

On Tue, Jan 05, 2010 at 11:48:47AM -0500, Tom spot Callaway wrote:
> On 01/05/2010 11:30 AM, Jesse Keating wrote:
> > On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote:
> >> On the other hand, with the
> >> guideline being so widely ignored, I'm not in a hurry to do work to
> >> comply with it ...
> >
> > Isn't that a chicken/egg problem?
>
> It really is. I mean, we could create the "Packaging Police" to run
> around and enforce the guidelines by force (either by fixing them
> manually, or by threatening maintainers until they do it), but is that
> really what we want?

Not for all packaging policies, but for some I think that would be a
good idea. Pick a set of policies we think are particularly important
to enforce & can be automatically checked, and declare any non-compliant
ones will be dropped in the next fedora release unless fixed.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 04:13 PM
Jon Ciesla
 
Default Our static Libraries packaging guidelines once more

Tom "spot" Callaway wrote:

On 01/05/2010 11:30 AM, Jesse Keating wrote:


On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote:


On the other hand, with the
guideline being so widely ignored, I'm not in a hurry to do work to
comply with it ...


Isn't that a chicken/egg problem?



It really is. I mean, we could create the "Packaging Police" to run
around and enforce the guidelines by force (either by fixing them
manually, or by threatening maintainers until they do it), but is that
really what we want?

~spot



No. Too bad though, I had visions of spiffy new uniforms.

That aside, I'd love to have all packages in total Guidlines compliance.

I'd also love to be rich. And thinner.

-J

--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 04:16 PM
"Tom "spot" Callaway"
 
Default Our static Libraries packaging guidelines once more

On 01/05/2010 12:08 PM, Daniel P. Berrange wrote:
> Not for all packaging policies, but for some I think that would be a
> good idea. Pick a set of policies we think are particularly important
> to enforce & can be automatically checked, and declare any non-compliant
> ones will be dropped in the next fedora release unless fixed.

Well, I think a reasonable alternative would be to add those policies to
the AutoQA infrastructure, and if the package fails the check, it
doesn't get tagged and the packager gets an email explaining the
failure. That will get things fixed up.

~spot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 04:23 PM
"Daniel P. Berrange"
 
Default Our static Libraries packaging guidelines once more

On Tue, Jan 05, 2010 at 12:16:13PM -0500, Tom spot Callaway wrote:
> On 01/05/2010 12:08 PM, Daniel P. Berrange wrote:
> > Not for all packaging policies, but for some I think that would be a
> > good idea. Pick a set of policies we think are particularly important
> > to enforce & can be automatically checked, and declare any non-compliant
> > ones will be dropped in the next fedora release unless fixed.
>
> Well, I think a reasonable alternative would be to add those policies to
> the AutoQA infrastructure, and if the package fails the check, it
> doesn't get tagged and the packager gets an email explaining the
> failure. That will get things fixed up.

That sounds good as long as AutoQA is reliable, not generating false
positives. I'd still also suggest that we have a rule drop all
packages reported by the FTBFS tests which aren't fixed by time of
Beta.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 04:27 PM
Tom Lane
 
Default Our static Libraries packaging guidelines once more

"Tom "spot" Callaway" <tcallawa@redhat.com> writes:
> On 01/05/2010 11:30 AM, Jesse Keating wrote:
>> On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote:
>>> On the other hand, with the
>>> guideline being so widely ignored, I'm not in a hurry to do work to
>>> comply with it ...
>>
>> Isn't that a chicken/egg problem?

> It really is.

Well, fwiw, I have to fix the same two spec files for the %define
problem, so I'm going to take care of this today while it's fresh in
mind. But there's a general issue that new things keep getting added
to the packaging guidelines and there's no very good mechanism to
detect whether existing packages ever get updated to comply.

regards, tom lane

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 04:33 PM
"Tom "spot" Callaway"
 
Default Our static Libraries packaging guidelines once more

On 01/05/2010 12:23 PM, Daniel P. Berrange wrote:
> On Tue, Jan 05, 2010 at 12:16:13PM -0500, Tom spot Callaway wrote:
>> On 01/05/2010 12:08 PM, Daniel P. Berrange wrote:
>>> Not for all packaging policies, but for some I think that would be a
>>> good idea. Pick a set of policies we think are particularly important
>>> to enforce & can be automatically checked, and declare any non-compliant
>>> ones will be dropped in the next fedora release unless fixed.
>>
>> Well, I think a reasonable alternative would be to add those policies to
>> the AutoQA infrastructure, and if the package fails the check, it
>> doesn't get tagged and the packager gets an email explaining the
>> failure. That will get things fixed up.
>
> That sounds good as long as AutoQA is reliable, not generating false
> positives. I'd still also suggest that we have a rule drop all
> packages reported by the FTBFS tests which aren't fixed by time of
> Beta.

Sure, but even if it did generate a false positive, the build would
still be there, just not tagged. Rel-eng could tag the package manually
while fixing the test to prevent the false positive.

~spot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2010, 04:34 PM
"Tom "spot" Callaway"
 
Default Our static Libraries packaging guidelines once more

On 01/05/2010 12:27 PM, Tom Lane wrote:
> But there's a general issue that new things keep getting added
> to the packaging guidelines and there's no very good mechanism to
> detect whether existing packages ever get updated to comply.

You're right. I'm hopeful that the items which can be checked via
automation will be done via AutoQA, but for those that can't, we will
still depend on packagers to be responsible.

~spot

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

Thread Tools




All times are GMT. The time now is 10:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org