Fedora packaging in Gentoo (diskuse)

[Honz]

Too loooong....
http://www.youtube.com/watch?v=QrtydD2u1N0&feature=kp

[kotrcka]

end tú inglyš.

[pavlix]

Předpokládám, že se mi právě ozvali dva zapálení fedoří maintaineři.

[kotrcka]

jes. ajm mejntejnyng máj oun mäšín.

[kavol]

You won't be able to do local builds easily as they rely on the local RPM metadata. I didn't package the tools necessary to do a local mockbuild as I didn't need it.

I believe I've seen a tool that is able to mirror the package database in different formats, but I wouldn't recommend(*) using that; mock is the way to go

(*) really, don't do that, I've seen all kinds of troubles having their origin in build environment differences that haunt our RHEL developers

[pavlix]

I like local builds because they are much quicker to tweak and quilt setup doesn't always do the job well. Mock is too slow and too complicated for many developer tasks. That could be more or less fixed by adding --nodeps to fedpkg compile.

[kavol]

Mock is too slow and too complicated for many developer tasks.

well ... in that case you should rethink the workflow probably, because I usually do not need to run mockbuild more than once for each release, so I'm not bothered by the slowness

and I'm not getting the "too complicated" part - for packager, it's just a matter of `fedpkg mockbuild` ... for the mock package maintainer, don't know how much it is tied to Fedora (e.g. the mentioned python version issue etc.) but I thought it is pretty universal?

[pavlix]

well ... in that case you should rethink the workflow probably

I love when people ask me to use a less effective workflow just because they think it's the right thing to do.

because I usually do not need to run mockbuild more than once for each release, so I'm not bothered by the slowness

I thought it was pretty clear that I'm not talking about basic maintainance tasks like bumping a release, rebuilding and leaving it until a new one comes. But to be honest, I'm not even using a local mockbuild for that, instead I'm using koji build --scratch.

and I'm not getting the "too complicated" part - for packager, it's just a matter of `fedpkg mockbuild`

I'm not specifically talking about cases fedpkg mockbuild and waiting for a resulting RPM works well.

The use case for local builds is when you need to repeatedly try to compile the source with relatively small changes until the result of the compilation is good. From SUSE folks I know they're using quilt setup for that but that doesn't work for all packages, although it has the advantage of keeping the patches ready for editing. You could theoretically use rhpkg prep but that doesn't do the configure stage which is not a simple cut-n-paste as it uses some system-level rpmbuild variables.

When you're done with that, a slow final koji build is a natural followup, as you need to handle the dependencies properly and you want to get the installable RPM. Sometimes a local mock build can be useful as an alternative to the koji build, but that's another topic.

[kavol]

well ... in that case you should rethink the workflow probably

I love when people ask me to use a less effective workflow just because they think it's the right thing to do.

I can hardly imagine that a workflow that does not rely on a slow tool (be it mock or koji) that much could be less effective than the one which makes extensive use of it

I thought it was pretty clear that I'm not talking about basic maintainance tasks like bumping a release, rebuilding and leaving it until a new one comes. But to be honest, I'm not even using a local mockbuild for that, instead I'm using koji build --scratch.

but that's the only point where do you need to actually build the package, be it local rpmbuild/mock/koji (the last being the slowest in a typical case, so ...) - I'm not getting why do you talk about mock slowness then ...

I'm not specifically talking about cases fedpkg mockbuild and waiting for a resulting RPM works well.

I'm completely lost then ...

The use case for local builds is when you need to repeatedly try to compile the source with relatively small changes until the result of the compilation is good.

ok, but "compile the source" != "build the package" ...

seems we're too generic here, I'd need some concrete example to understand what are you trying to achieve ... but I can live without that happily

[pavlix]

I don't know how much actual development development you're doing except the fact that it's not your everyday job. But for a developer, build an RPM package from dist-git is a very tiny portion of his job. And for nontrivial packages, it's still a small portion of the packaging as well. No matter that the final step is to build a set of RPM packages.

You don't actually need to have a specific example, just remember that your favorite package maintainers and developers need to touch and test the code that isn't present in the dist-git verbatim but is produced by the %prep phase and also part of the %configure phase as RPM is pretty dumb and doesn't distinguish between configuration and compilation, as some other build systems do.

When I want to check whether something works while doing my own little tweaks, I need to step in the build process when it's about to call make, or I can live with stepping in just after. That's possible with mock as well, but it's incredibly slow. And it's just as incredibly slow to reset the state with mock, as its caching capabilities don't seem to be very good.

That you can live without that is fair. Bud to advise an active developer to use a slower way using mock just because you're not familiar with the faster way is just ridiculous.

[kolcon]

az to bude ke cteni a ne jeden dlouhy souvisly blok textu, s dlouhymi souvetimi, u ktereho je problem poznat, kde to vlastne zacina a kde konci, a o cem to vlastne jako je, tak si to pak mozna prectu ;)

[Bedňa]

To sa čudeješ, vieš koľko Jílkových blogových zápiskov tu musel prečítať, to musí zanechať stopy Mňa by skôr od Pavlixa zaujímalo prečo chce balíčkovať bez riešenia závislostí na konkrétnej vetve Fedorky, alebo mi niečo uniklo?

[pavlix]

To sa čudeješ, vieš koľko Jílkových blogových zápiskov tu musel prečítať, to musí zanechať stopy

Kdo se pročetl až na konec, tak ví, že ten článek je needitovaný výblitek, protože na nějaké vyšperkované povídání jsem neměl čas. Už tak jsem šel spát dost pozdě.

Mňa by skôr od Pavlixa zaujímalo prečo chce balíčkovať bez riešenia závislostí na konkrétnej vetve Fedorky, alebo mi niečo uniklo?

Pokud reaguješ na článek, tak uniklo. Ty zabalené nástroje komunikují s fedoří build infrastrukturou, která závislosti řeší tak jak je u RPM distribuce zvykem. Pokud na komentář výše, tak fedpkg compile používám proto, abych bez zbytečného zdržování dostal adresář, ve kterém můžu dělat úpravy a pouštět make.

Popravdě řečeno, kontrola závislostí ve fedpkg compile je úplně na hovno. Ve Fedoře stejně předtím zavolám yum-builddep a tudíž mám závislosti nainstalované a zkontrolované. Mimo Fedoru nemá fedpkg compile data pro nějakou relevantní kontrolu.

[Bedňa]

Nedocvaklo mi to, trochu viac textu ako býva zvykom ;)

[David Jaša]

Předpokládám, že se mi právě ozvali dva zapálení fedoří maintaineři.

hm, třetí do party.

[pavlix]

:D