Re: rpm 5.4.10 for testing in th-test
On Tue, Sep 11, 2012 at 11:06:45PM -0400, Jeffrey Johnson wrote:
There's no well defined semantic for
Provides: group(mpd)
even if PLD has adopted some convention afaik. The
Provides: group(mpd)
is just a string and (imho) should be removed
if there are problems unless there is truly some
explicit PLD implementation that relies on the adopted
convention.
There is.
PLD. Packages with 'Provides: group(mpd)' call the '%groupadd' macro
during installation, which creates the group if it is not already
defined. When uninstalled they call the '%groupremove' macro.
The same 'group(mpd)' may be provided by multiple packages (probably not
much sense with the 'mpd' group, but important for other cases) and the
group will be removed only when the last package which provides it is
removed. So the 'Provides: user(*)' and 'Provides: group(*)' are
critical for our %{user,group}{add,remove} macros.
Other solutions to the problem (multiple packages using the same
user/groups) would be:
- including every system uid/gid in the 'setup' package.
Disadvantages: lots of unneeded user and groups defined on every PLD
system and the need to update the setup package whenever user/group is
needed for anything else.
- providing each such user/group/usergroup via a single packages
Disadvantages: some packages would be created only to hold a single
user or group definition.
- never removing users/groups added
Disadvantages: mess left after uninstalled packages
Our useradd/groupadd macros with 'Provides: user/group(*)' seem to be
quite an elegant solution in comparison and RPM 5.x still doesn't seem
to provide anything better.
Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: texlive 2012
On 12.09.2012 08:23, Zsolt Udvari wrote: The reason of splitting: texlive is arch-dependent, texlive-texmf is arch-independent. The versions are different. can this reason be marked void with rpm5? in other words, does rpm5 support noarch subpackages? just mark them, nothing more complex in it, it's fault of packager putting invliad content here, we have ftp automation to alert on some mistakes. jbj: i know you're reading :) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: texlive 2012
On 12.09.2012 08:23, Zsolt Udvari wrote: Some time ago, when I've split texlive.spec to texlive.spec and texlive-texmf.spec many things was adhoc-style:) So first need a big-big cleaning and I think after this the maintain will be simple. With one big spec: the build will be hard, see above, as you wrote: you'll build the texlive.spec's texlive-bin and after you'll install these packages and build texlive.spec's texlive-texmf? why is building hard? you do first rpmbuild, and alter you handle only %files thus: $ ./repackage.sh textlive.spec will invoke %install and produce .rpm files and after that if you do not need to modify $RPM_BUILD_ROOT, you can just invoke: $ ./repackage.sh textlive.spec -bb this will not invoke %install again, just will produce .rpm packages (repackage.sh is just frontend to rpmbuild --short-circuit) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th development plans
On Tue, 04 Sep 2012, Lukasz Kies wrote: 2012/9/4 Jan Rękorajski bagg...@pld-linux.org: On Tue, 04 Sep 2012, Arkadiusz Miśkiewicz wrote: On Tuesday 04 of September 2012, Jan Rękorajski wrote: Hi, After making a snapshot, and having (development wise) stable package set, I want to start refreshing the distribution. This means big changes in the near future to get PLD back to being modern (or at least up-to-date) wrt current Linux world. Below I present a plan (a.k.a The Roadmap) for Th: New texlive, new ffmpeg, new mesa (soon 9.0), new xserver (soon 1.13) ? :-) Sure, but let's take one step at a time, I upgraded db and then I want to go with rpm (which seems to have some rpmbuild problems related to python, BTW :/) Hi, Maybe add some wiki page, where we could add comments about progress, dates and synchronize work with each other? Done, not much content yet, but we can start from here. http://www.pld-linux.org/Th-next -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsatmimuw.edu.pl bagginsatpld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 5.4.10 for testing in th-test
On Sep 12, 2012, at 2:56 AM, Jacek Konieczny jaj...@jajcus.net wrote:
On Tue, Sep 11, 2012 at 11:06:45PM -0400, Jeffrey Johnson wrote:
There's no well defined semantic for
Provides: group(mpd)
even if PLD has adopted some convention afaik. The
Provides: group(mpd)
is just a string and (imho) should be removed
if there are problems unless there is truly some
explicit PLD implementation that relies on the adopted
convention.
There is.
OK.
PLD. Packages with 'Provides: group(mpd)' call the '%groupadd' macro
during installation, which creates the group if it is not already
defined. When uninstalled they call the '%groupremove' macro.
The same 'group(mpd)' may be provided by multiple packages (probably not
much sense with the 'mpd' group, but important for other cases) and the
group will be removed only when the last package which provides it is
removed. So the 'Provides: user(*)' and 'Provides: group(*)' are
critical for our %{user,group}{add,remove} macros.
Other solutions to the problem (multiple packages using the same
user/groups) would be:
- including every system uid/gid in the 'setup' package.
Disadvantages: lots of unneeded user and groups defined on every PLD
system and the need to update the setup package whenever user/group is
needed for anything else.
- providing each such user/group/usergroup via a single packages
Disadvantages: some packages would be created only to hold a single
user or group definition.
- never removing users/groups added
Disadvantages: mess left after uninstalled packages
Our useradd/groupadd macros with 'Provides: user/group(*)' seem to be
quite an elegant solution in comparison and RPM 5.x still doesn't seem
to provide anything better.
Heh: @rpm5.org has a complete copy of shadowutils
reworked into lua module(s) in order to be able
to perform _EXACTLY_ what useradd/groupadd do
in cross-compilation (and cross-install) environments
using embedded lua and shadowutils (and checkconf).
RPM+LUA+SHADOWUTILS is/was arguably better at the time (~2008).
rpm also embeds augeas, so augtool commands can
be run that do not only add/delete but also permit
modification under an augtool-like DSL programatically.
More recently, rpm embeds sqlite3 and there are
virtual tables to user/group management: the intent
is/was to add transactional support and a 2-phase commit
to /etc/passwd/gtoup management well integrated into
Transactionally Protected Package Management
At the moment user/group management is RO and without
transactional support … there's been little reason
to complete the work so far.
But this isn't the time/pace to discuss relative merits
of user/group management … the rpmdsCompare needs to
be extended to include the namespace in the comparison.
73 de Jeff
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - add filetriggers directory
On 12.09.2012 14:51, baggins wrote: commit e9eb00afc48b027786d4fd5c23e6cff20acc8df8 Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:33:26 2012 +0200 - add filetriggers directory ... %dir /var/lib/rpm +%dir /var/lib/rpm/filetriggers why filetriggers in /var/lib? due /usr separation? maybe put to /lib/rpm instead then? more FHS friendly imho -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - add filetriggers directory
On Sep 12, 2012, at 9:43 AM, Elan Ruusamäe wrote: On 12.09.2012 14:51, baggins wrote: commit e9eb00afc48b027786d4fd5c23e6cff20acc8df8 Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:33:26 2012 +0200 - add filetriggers directory ... %dir /var/lib/rpm +%dir /var/lib/rpm/filetriggers why filetriggers in /var/lib? due /usr separation? maybe put to /lib/rpm instead then? more FHS friendly imho Adding non-rpmdb data (like filetriggers) into a directory that includes a Berkeley DB dbenv blocks further performance increases and addressing the permission changes that are needed to permit RO access with the ability to create locks (i.e. RO MUST be able to write to __db* files in order to register locks). I too would suggest choosing some other path for filetriggers than /var/lib/rpm. 73 de Jeff -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Wed, Sep 12, 2012 at 01:51:26PM +0200, baggins wrote: commit c73c505644fa30c3e32a596dbc4aea90cfac0bcc Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:24:58 2012 +0200 - set binary payload to xzdio (same as lzdio, but uses current xz) %_source_payload w9.gzdio -%_binary_payload w9.lzdio +%_binary_payload w9.xzdio What is the minimal rpm version that supports xzdio (and what was that supports lzdio)? If not the same, there must exist some easy upgrade path. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Sep 12, 2012, at 12:20 PM, Jakub Bogusz wrote: On Wed, Sep 12, 2012 at 01:51:26PM +0200, baggins wrote: commit c73c505644fa30c3e32a596dbc4aea90cfac0bcc Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:24:58 2012 +0200 - set binary payload to xzdio (same as lzdio, but uses current xz) %_source_payload w9.gzdio -%_binary_payloadw9.lzdio +%_binary_payloadw9.xzdio What is the minimal rpm version that supports xzdio (and what was that supports lzdio)? Counting Mandriva backports: rpm-4.4.2.3 (though its a bloody mess in MES5) If not the same, there must exist some easy upgrade path. rpm2cpio.sh | cpio -dim Guaranteed to upgrade and not particularly hard. 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Wed, 12 Sep 2012, Jakub Bogusz wrote: On Wed, Sep 12, 2012 at 01:51:26PM +0200, baggins wrote: commit c73c505644fa30c3e32a596dbc4aea90cfac0bcc Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:24:58 2012 +0200 - set binary payload to xzdio (same as lzdio, but uses current xz) %_source_payload w9.gzdio -%_binary_payload w9.lzdio +%_binary_payload w9.xzdio What is the minimal rpm version that supports xzdio (and what was that supports lzdio)? None of our rpm4 supports xzdio, but rpm package by itself is build with gzdio payload. If not the same, there must exist some easy upgrade path. rpm-*.rpm packages are built with gzdio payload so it should be possible to upgrade without problems using any rpm version. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsatmimuw.edu.pl bagginsatpld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Sep 12, 2012, at 12:37 PM, Jan Rękorajski wrote: On Wed, 12 Sep 2012, Jakub Bogusz wrote: On Wed, Sep 12, 2012 at 01:51:26PM +0200, baggins wrote: commit c73c505644fa30c3e32a596dbc4aea90cfac0bcc Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:24:58 2012 +0200 - set binary payload to xzdio (same as lzdio, but uses current xz) %_source_payloadw9.gzdio -%_binary_payload w9.lzdio +%_binary_payload w9.xzdio What is the minimal rpm version that supports xzdio (and what was that supports lzdio)? None of our rpm4 supports xzdio, but rpm package by itself is build with gzdio payload. The back port isn't impossibly hard. but you want to start with ~rpm-5.1.4 iirc. If not the same, there must exist some easy upgrade path. rpm-*.rpm packages are built with gzdio payload so it should be possible to upgrade without problems using any rpm version. Shipping *.src.rpm with anything except ZLIB compression is asking for incompatibilities. Using rpm2cpio (or rpm2cpio.sh) to unpack a *.src.rpm and rebuilding with compression du jour is the proper upgrade path. Meanwhile LZMA - XZ transition got smeared out for years and isn't an RPM issue per se. 73 de Jeff -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsatmimuw.edu.pl bagginsatpld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Wed, 12 Sep 2012, Jeffrey Johnson wrote: On Sep 12, 2012, at 12:37 PM, Jan Rękorajski wrote: On Wed, 12 Sep 2012, Jakub Bogusz wrote: On Wed, Sep 12, 2012 at 01:51:26PM +0200, baggins wrote: commit c73c505644fa30c3e32a596dbc4aea90cfac0bcc Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:24:58 2012 +0200 - set binary payload to xzdio (same as lzdio, but uses current xz) %_source_payload w9.gzdio -%_binary_payload w9.lzdio +%_binary_payload w9.xzdio What is the minimal rpm version that supports xzdio (and what was that supports lzdio)? None of our rpm4 supports xzdio, but rpm package by itself is build with gzdio payload. The back port isn't impossibly hard. but you want to start with ~rpm-5.1.4 iirc. IMO it's a waste of time to backport something to a software that will be obsolete real soon now (rpm4 in this case). If not the same, there must exist some easy upgrade path. rpm-*.rpm packages are built with gzdio payload so it should be possible to upgrade without problems using any rpm version. Shipping *.src.rpm with anything except ZLIB compression is asking for incompatibilities. We are shipping binary (*.ARCH.rpm) rpm packages with rpm using ZLIB, so it should be always possible to install new rpm. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsatmimuw.edu.pl bagginsatpld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Sep 12, 2012, at 1:02 PM, Jan Rękorajski wrote: Shipping *.src.rpm with anything except ZLIB compression is asking for incompatibilities. We are shipping binary (*.ARCH.rpm) rpm packages with rpm using ZLIB, so it should be always possible to install new rpm. Good: zlib (as used @rpm5.org) is --rsyncable (and afaik LZMA/XZ is not). If both the remote/local packages are --rsyncable, then you SHOULD see larger bandwidth reductions than available with XZ compression and no --rsyncable afaik. The savings is a difficult measurement however, harder than just comparing file sizes. 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD-update-TODO
On Tuesday 24 of July 2012 17:32:08 Arkadiusz Miśkiewicz wrote:
On Tuesday 24 of July 2012, Jakub Bogusz wrote:
Has git migration stopped PLD-update-TODO updates?
It is not changed to work with git (yet).
Some people (like me) can't develop without this file.I'm waiting for it. Good
luck.
--
Łukasz Głębicki mail/rot13:yhxnf...@cbfg.cy PLD/Linux Team
gg:246267Linux Registered User #318551 blekot:{irc,skype}
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Wed, Sep 12, 2012 at 06:37:59PM +0200, Jan Rękorajski wrote: On Wed, 12 Sep 2012, Jakub Bogusz wrote: On Wed, Sep 12, 2012 at 01:51:26PM +0200, baggins wrote: commit c73c505644fa30c3e32a596dbc4aea90cfac0bcc Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:24:58 2012 +0200 - set binary payload to xzdio (same as lzdio, but uses current xz) %_source_payload w9.gzdio -%_binary_payload w9.lzdio +%_binary_payload w9.xzdio What is the minimal rpm version that supports xzdio (and what was that supports lzdio)? None of our rpm4 supports xzdio, but rpm package by itself is build with gzdio payload. If not the same, there must exist some easy upgrade path. rpm-*.rpm packages are built with gzdio payload so it should be possible to upgrade without problems using any rpm version. But rpm.rpm requires also some library rpms, e.g.: - db5.3 is something new in Th - xz 5.1.x (5.0.x dated few months ago won't satisfy) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD-update-TODO
On Wed, Sep 12, 2012 at 07:33:27PM +0200, Lukasz Glebicki wrote: On Tuesday 24 of July 2012 17:32:08 Arkadiusz Miśkiewicz wrote: On Tuesday 24 of July 2012, Jakub Bogusz wrote: Has git migration stopped PLD-update-TODO updates? It is not changed to work with git (yet). Some people (like me) can't develop without this file.I'm waiting for it. Good luck. It's normally updated since a few days after the cited posts. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On 09/12/2012 07:49 PM, Jeffrey Johnson wrote: %_source_payloadw9.gzdio -%_binary_payload w9.lzdio +%_binary_payload w9.xzdio ... Shipping *.src.rpm with anything except ZLIB compression is asking for incompatibilities. src.rpm is not touched, it's still w9.gzdio -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - set binary payload to xzdio (same as lzdio, but uses current xz) - add settings provided by patche
On Wed, 12 Sep 2012, Jakub Bogusz wrote: On Wed, Sep 12, 2012 at 06:37:59PM +0200, Jan Rękorajski wrote: On Wed, 12 Sep 2012, Jakub Bogusz wrote: On Wed, Sep 12, 2012 at 01:51:26PM +0200, baggins wrote: commit c73c505644fa30c3e32a596dbc4aea90cfac0bcc Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:24:58 2012 +0200 - set binary payload to xzdio (same as lzdio, but uses current xz) %_source_payload w9.gzdio -%_binary_payload w9.lzdio +%_binary_payload w9.xzdio What is the minimal rpm version that supports xzdio (and what was that supports lzdio)? None of our rpm4 supports xzdio, but rpm package by itself is build with gzdio payload. If not the same, there must exist some easy upgrade path. rpm-*.rpm packages are built with gzdio payload so it should be possible to upgrade without problems using any rpm version. But rpm.rpm requires also some library rpms, e.g.: - db5.3 is something new in Th - xz 5.1.x (5.0.x dated few months ago won't satisfy) Good point, I'll revert that change then. As there is no real difference between lzdio and xzdio that I can find, we can postpone the switch for later. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsatmimuw.edu.pl bagginsatpld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - add filetriggers directory
On Wed, 12 Sep 2012, Elan Ruusamäe wrote: On 12.09.2012 14:51, baggins wrote: commit e9eb00afc48b027786d4fd5c23e6cff20acc8df8 Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:33:26 2012 +0200 - add filetriggers directory ... %dir /var/lib/rpm +%dir /var/lib/rpm/filetriggers why filetriggers in /var/lib? due /usr separation? maybe put to /lib/rpm instead then? more FHS friendly imho What about /etc/rpm/filetriggers ? Let's try not to needlesly multiply directories. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsatmimuw.edu.pl bagginsatpld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - add filetriggers directory
On Sep 12, 2012, at 2:32 PM, Jan Rękorajski wrote: On Wed, 12 Sep 2012, Elan Ruusamäe wrote: On 12.09.2012 14:51, baggins wrote: commit e9eb00afc48b027786d4fd5c23e6cff20acc8df8 Author: Jan Rękorajski bagg...@pld-linux.org Date: Wed Sep 12 13:33:26 2012 +0200 - add filetriggers directory ... %dir /var/lib/rpm +%dir /var/lib/rpm/filetriggers why filetriggers in /var/lib? due /usr separation? maybe put to /lib/rpm instead then? more FHS friendly imho What about /etc/rpm/filetriggers ? FYI: this is Mandriva filetriggers and is likely to be removed in favor of using existing %trigger* scripts, which permit file paths, directory paths (with trailing /), and glob expressions to be used. The reason for _NOT_ using Mandriva file triggers is that %trigger scripts are wholly contained within package metadata and so can be debugged more easily than a pile of stuff that is read, matched, and run (and rpm is blamed when the opaque stuff breaks). Try-and-see: there's likely still a bit more to do, but the basics have been in place with test cases for several years now. Let's try not to needlesly multiply directories. FYI: rpm-5.4.10 is already using /var/lib/wdj path for sqlite3 and (soon) libgit2 development. And /var/cache/rpm is likely to be used for secondary indices and perhaps transactional logs by end-of-year. Reliability/performance is increased if the data store, the __db* cache, and the logs can be put on different partitions/disks. 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
