Hi guys,
I'd like to gather some input on versioning schemes used for packaging
SCM snapshots. Why do we care at all? Ignoring the source pkg and the
changes file for the moment, the package version is meant to tell the
user exactly which state of the software was provided to him. When you
package an upstream tarball, you implicitly provide information about
what was released and when. And the package build is reproducable, it
won't change how often you download the tarball referenced in Source:.
Thus it's enough to just have sth. like this in your spec file:
Version: 1.2.3
So if you have to package a (random) SCM snapshot, you want to make sure
that it's obvious which commit you picked, so that others can confirm
and eventually repeat the build. Here's a small list of flavors that
I've come across or used myself. Please not that I replaced the stable
(upstream) version with X, since that's not the part I'm interested
here. Also, the word "git" can be replaced by whatever SCM at hand:
1) X+git
2) X_20041122git
3) X+git20111213
4) X.a258.g003e7e3
5) X+git.1363873583.8dfab15
Albeit you can discuss the format differences, 2) and 3) are much better
than 1) since they at least broadly state when the SCM snapshot was
taken. 4) Does a better job by providing the commit number/hash but
breaks RPM upgradeability. Random commit hashes aren't upgradeable
right? So the best version is indeed number 5), where the first number
is the commit date and the second one is the commit hash. The date
assures upgradability, because it increments always linearly and the
commit hash provides for reproducability.
You can of course argue about dots vs, any other separating paragraph.
Also, instead of "+git", you may prefer sth. different (along as it
won't break RPM's version comparison mechanism).
TL;DR
=====
My recommendation would be to (at least loosely) follow pattern 5)
versioning if you ever have to package from SCMs. While devel projects
are rather free to do whatever they prefer, I'd say it's appropriate for
Factory submissions.
Bonus
=====
There is absolutely no reason to do this manually. Use the tar_scm
source service (in disabled or local_only mode !!!) if you want to fully
automate this. Here are some examples:
Cloud:OpenStack:Master / openstack-utils
devel:languages:go / go-assert
--
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
hi all
Hoping you are my right address
I send you "conflicts.txt" for 13.1 RC1 (down)
Please look too for
acroread -> ask for libidn.so11 it is on the DVD and installed
if wanted -> syslog-ng -> ask for libevtlog.so. -> libnet.so1
I tell you, libevtlog is only in eventlog from feodora
There is also a Problem with amarok-Update (?)
sorry for my english
Thank you
Regards
Jens
conflicts:
#### YaST2 conflicts list - generated 2013-10-21 09:31:20 ####
libQtGStreamer-0.10.so.0()(64bit), benötigt von
kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten
[ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] Deinstallation von digikam-3.4.0-2.1.4.x86_64
[ ] veraltetes digikam-3.4.0-2.1.4.x86_64 behalten
libkdecore.so.5, benötigt von kipi-plugins-3.5.0-2.4.2.i586, wird
von keinem Repository angeboten
[ ] veraltetes kipi-plugins-3.4.0-2.1.4.x86_64 behalten
[ ] kipi-plugins-3.5.0-2.4.2.i586 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] Deinstallation von kipi-plugins-3.4.0-2.1.4.x86_64
libQtGStreamer-0.10.so.0()(64bit), benötigt von
kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten
[ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] veraltetes kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 behalten
[ ] Deinstallation von kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64
libQtGStreamer-0.10.so.0()(64bit), benötigt von
kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten
[ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] Deinstallation von kipi-plugins-geolocation-3.4.0-2.1.4.x86_64
[ ] veraltetes kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 behalten
#### YaST2 conflicts list END ###
conflicts.txt
#### YaST2 conflicts list - generated 2013-10-21 09:31:20 ####
libQtGStreamer-0.10.so.0()(64bit), benötigt von
kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten
[ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] Deinstallation von digikam-3.4.0-2.1.4.x86_64
[ ] veraltetes digikam-3.4.0-2.1.4.x86_64 behalten
libkdecore.so.5, benötigt von kipi-plugins-3.5.0-2.4.2.i586, wird
von keinem Repository angeboten
[ ] veraltetes kipi-plugins-3.4.0-2.1.4.x86_64 behalten
[ ] kipi-plugins-3.5.0-2.4.2.i586 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] Deinstallation von kipi-plugins-3.4.0-2.1.4.x86_64
libQtGStreamer-0.10.so.0()(64bit), benötigt von
kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten
[ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] veraltetes kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 behalten
[ ] Deinstallation von kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64
libQtGStreamer-0.10.so.0()(64bit), benötigt von
kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten
[ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren
einiger Abhängigkeiten
[ ] Deinstallation von kipi-plugins-geolocation-3.4.0-2.1.4.x86_64
[ ] veraltetes kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 behalten
#### YaST2 conflicts list END ###
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I maintain httrack and httrack-3.47.24 installs fine on 12.3
With openSUSE 13.1 it fails:
The error is:
Error: Subprocess failed. Error: RPM failed: error: unpacking of
archive failed on file /usr/share/httrack/html: cpio: rename failed -
Is a directory
It is actually not a directory, it's a symbolic link
> ls -l
total 32
lrwxrwxrwx 1 root root 28 Aug 29 14:12 html -> ../doc/packages/httrack/html
drwxr-xr-x 2 root root 4096 Aug 29 14:12 lang
-rw-r--r-- 1 root root 22442 Aug 26 08:51 lang.def
-rw-r--r-- 1 root root 159 Aug 26 08:51 lang.indexes
Is a symbolic link from /usr/share/html to
/usr/share/doc/packages/httrack/html no longer valid?
Greg
--
Greg Freemyer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
Would a good home location for Joomla package [Content Management System]
be the following:
https://build.opensuse.org/project/show/server:php:applications
I did a test compile and it builds and installs ok [1]
Just build latest relesed versions from
http://www.joomla.org/download.html
Runs ontop of a lamp subsystem.
How can it be submitted to this category ?
Would anyone be interested in using this package ?
Cheers Glenn
[1] Joomla package - test compile
https://build.opensuse.org/package/show/home:doiggl/joomla
Full build log:
https://build.opensuse.org/package/rawlog/home:doiggl/joomla/openSUSE_Facto…
From logs:
.
.
[ 90s] 3 packages and 0 specfiles checked; 0 errors, 28 warnings.
[ 90s]
[ 90s] ... creating baselibs
[ 90s] ... saving built statistics
[ 90s] ... saving built packages
[ 90s] /home/abuild/rpmbuild/RPMS/noarch/joomla-3.1.5-8.1.noarch.rpm
[ 90s]
/home/abuild/rpmbuild/RPMS/noarch/joomla-installation-3.1.5-8.1.noarch.rpm
[ 90s] /home/abuild/rpmbuild/SRPMS/joomla-3.1.5-8.1.src.rpm
[ 91s] /home/abuild/rpmbuild/OTHER/_statistics
[ 91s] /home/abuild/rpmbuild/OTHER/rpmlint.log
[ 91s]
[ 91s] cloud132 finished "build joomla.spec" at Fri Oct 4 15:02:26 UTC
2013.
[ 91s]
[ 94s] [ 82.922491] SysRq : Power Off
[ 94s] [ 83.095185] Power down.
[ 94s] build: extracting built packages...
[ 95s] joomla-3.1.5-8.1.noarch.rpm
[ 95s] joomla-installation-3.1.5-8.1.noarch.rpm
[ 95s] joomla-3.1.5-8.1.src.rpm
Architecture: i586
joomla-3.1.5-8.1.noarch.rpm
joomla-3.1.5-8.1.src.rpm
joomla-installation-3.1.5-8.1.noarch.rpm
Architecture: x86_64
joomla-3.1.5-8.1.noarch.rpm
joomla-3.1.5-8.1.src.rpm
joomla-installation-3.1.5-8.1.noarch.rpm
RPMLINT report:
===============
joomla.noarch: W: script-without-shebang
/srv/www/htdocs/joomla/administrator/components/com_users/helpers/users.php
joomla.noarch: W: script-without-shebang
/srv/www/htdocs/joomla/administrator/components/com_users/views/users/tmpl/default.php
joomla.noarch: W: script-without-shebang
/srv/www/htdocs/joomla/administrator/components/com_users/views/note/tmpl/index.html
joomla.noarch: W: script-without-shebang
/srv/www/htdocs/joomla/administrator/components/com_users/views/notes/index.html
joomla.noarch: W: script-without-shebang
/srv/www/htdocs/joomla/administrator/components/com_users/views/note/index.html
joomla.noarch: W: script-without-shebang
/srv/www/htdocs/joomla/administrator/components/com_users/views/notes/tmpl/index.html
joomla-installation.noarch: W: script-without-shebang
/srv/www/htdocs/joomla/installation/template/index.php
This text file has executable bits set or is located in a path dedicated
for
executables, but lacks a shebang and cannot thus be executed. If the
file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.
joomla.noarch: W: pem-certificate
/srv/www/htdocs/joomla/libraries/joomla/http/transport/cacert.pem
Shipping a PEM certificate is likely wrong. If used for the default
configuration, this is insecure ( since the certificate is public ). If
this
is used for validation, ie a CA certificate store, then this must be kept
up
to date due to CA compromise. The only valid reason is for testing
purpose, so
ignore this warning if this is the case.
joomla.noarch: W: non-executable-script
/srv/www/htdocs/joomla/bin/keychain.php 0644L /usr/bin/env
This text file contains a shebang or is located in a path dedicated for
executables, but lacks the executable bits and cannot thus be executed.
If
the file is meant to be an executable script, add the executable bits,
otherwise remove the shebang or move the file elsewhere.
joomla.noarch: W: no-changelogname-tag
joomla-installation.noarch: W: no-changelogname-tag
joomla.src: W: no-changelogname-tag
There is no changelog. Please insert a '%changelog' section heading in
your
spec file and prepare your changes file using e.g. the 'osc vc' command.
joomla.noarch: W: name-repeated-in-summary C Joomla
joomla.src: W: name-repeated-in-summary C Joomla
The name of the package is repeated in its summary. This is often
redundant
information and looks silly in various programs' output. Make the
summary
brief and to the point without including redundant information in it.
joomla.src:71: W: macro-in-comment %{buildroot}
joomla.src:72: W: macro-in-comment %{name}
joomla.src:222: W: macro-in-comment %{apache_serverroot}
joomla.src:229: W: macro-in-comment %{apache_serverroot}
There is a unescaped macro after a shell style comment in the specfile.
Macros
are expanded everywhere, so check if it can cause a problem in this case
and
escape the macro with another leading % if appropriate.
joomla.noarch: W: invalid-license GPL
joomla-installation.noarch: W: invalid-license GPL
joomla.src: W: invalid-license GPL
The specified license string is not recognized. Please refer to
http://license.opensuse.org/ for the list of known licences and their
exact
spelling.
joomla.noarch: W: incorrect-fsf-address
/srv/www/htdocs/joomla/libraries/phpmailer/LICENSE
joomla.noarch: W: incorrect-fsf-address
/srv/www/htdocs/joomla/libraries/simplepie/idn/LICENCE
joomla.noarch: W: incorrect-fsf-address
/srv/www/htdocs/joomla/administrator/templates/hathor/LICENSE.txt
joomla.noarch: W: incorrect-fsf-address
/srv/www/htdocs/joomla/LICENSE.txt
joomla.noarch: W: incorrect-fsf-address
/srv/www/htdocs/joomla/libraries/idna_convert/LICENCE
The Free Software Foundation address in this file seems to be outdated or
misspelled. Ask upstream to update the address, or if this is a license
file,
possibly the entire file with a new copy available from the FSF.
joomla.noarch: W: files-duplicate
/srv/www/htdocs/joomla/media/jui/index.html
/srv/www/htdocs/joomla/administrator/components/com_finder/models/forms/index.html:/srv/www/htdocs/joomla/components/com_finder/views/search/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/statistics/index.html:/srv/www/htdocs/joomla/components/com_finder/helpers/html/index.html:/srv/www/htdocs/joomla/media/jui/css/index.html:/srv/www/htdocs/joomla/media/system/images/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/filters/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/notes/tmpl/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/filter/index.html:/srv/www/htdocs/joomla/media/system/images/modal/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/html/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/index.html:/srv/www/htdocs/joomla/components/com_finder/helpers/index.html:/srv/www/htdocs/joomla/modules/mod_
finder/i
ndex.html:/srv/www/htdocs/joomla/media/jui/js/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/stemmer/index.html:/srv/www/htdocs/joomla/media/jui/fonts/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/models/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/sql/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/note/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/note/tmpl/index.html:/srv/www/htdocs/joomla/plugins/system/highlight/index.html:/srv/www/htdocs/joomla/media/system/images/mooRainbow/index.html:/srv/www/htdocs/joomla/media/com_finder/js/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/index/index.html:/srv/www/htdocs/joomla/administrator/compone
nts/com_
users/views/notes/index.html:/srv/www/htdocs/joomla/media/com_finder/css/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/parser/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/statistics/index.html:/srv/www/htdocs/joomla/media/plg_system_highlight/index.html:/srv/www/htdocs/joomla/plugins/finder/categories/index.html:/srv/www/htdocs/joomla/media/system/css/index.html:/srv/www/htdocs/joomla/plugins/finder/contacts/index.html:/srv/www/htdocs/joomla/media/jui/img/index.html:/srv/www/htdocs/joomla/components/com_finder/views/search/tmpl/index.html:/srv/www/htdocs/joomla/components/com_finder/index.html:/srv/www/htdocs/joomla/media/com_finder/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/maps/index.html:/srv/www/htdocs/joomla/administrator/components/com_languages/views/overrides/index.html:/srv/www/htdocs/joomla/plugins/finder/newsfeeds/index.html:/srv/www/htdocs/joomla/media/jui/
less/ind
ex.html:/srv/www/htdocs/joomla/components/com_finder/controllers/index.html:/srv/www/htdocs/joomla/plugins/finder/tags/index.html:/srv/www/htdocs/joomla/plugins/finder/content/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/driver/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/statistics/tmpl/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/models/fields/index.html:/srv/www/htdocs/joomla/components/com_finder/models/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/controllers/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/index.html:/srv/www/htdocs/joomla/administrator/components/com_languages/views/overrides/tmpl/index.html:/srv/www/htdocs/joomla/media/system/index.html:/srv/www/htdocs/joomla/components/com_finder/views/index.html:/srv/www/htdocs/joomla/administrator/components/com_config/models/fields/index.html:/srv/www/htdocs/joomla/med
ia/syste
m/js/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_users/user/index.html:/srv/www/htdocs/joomla/plugins/finder/weblinks/index.html:/srv/www/htdocs/joo[
79.264141] serial8250: too much work for irq4
mla/administrator/components/com_finder/tables/index.html:/srv/www/htdocs/joomla/modules/mod_finder/tmpl/index.html
joomla.noarch: W: explicit-lib-dependency php5-zlib
You must let rpm find the library dependencies by itself. Do not put
unneeded
explicit Requires: tags.
3 packages and 0 specfiles checked; 0 errors, 28 warnings.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi everyone,
what is the preferred way to handle shared libraries? The package should go into the science repo, but feedback on how it's done in the standard repos is also welcome.
I've looked at https://en.opensuse.org/openSUSE:Shared_library_packaging_policy, but I still do not quite understand how to organise the %package sections:
Is it:
Name: libblah
…
%package -n %{name}%{sover}
…
%package devel
or rather:
Name: blah
...
%package -n lib%{name}%{sover}
…
%package devel
Do I retain the basic (lib)blah package for documentation, or should that go to -devel? If so, how do I suppress the empty default package?
Thanks a lot,
A.
--
Ansgar Esztermann
DV-Systemadministration
Max-Planck-Institut für biophysikalische Chemie, Abteilung 105
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 2013-09-22 11:33 (GMT+0400) Andrey Borzenkov composed:
> Cristian RodrÃguez composed:
>> last fbset release was in 1999, that is 14 years ago, nowadays all this
>> stuff is obsolete, replaced by Kernel mode setting (KMS)
> What is replacement user level tool for KMS?
> What is replacement user level tool for users who cannot use KMS?
> I perfectly understand removing it from installation media. But killing
> the package?
Ping!!!
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Apologies for the long email ...
I have updated open-iscsi in openSUSE Factory and 13.1 to work with
systemd. I have a couple of questions (below), but first some background
on what I'm trying to do.
As part of the process of updating open-iscsi to work with systemd, I
tried to take advantage of the fact that systemd can start socket-based
services on demand. This means that, if set up correctly, the iscsi
daemon does not need to be running until and unless it is needed.
To do this, I broke the open-iscsi System V init file into 3 services,
based on work being done on open-iscsi upstream:
- At the lowest level is the unit iscsid.socket
- The iscsid.service unit is tied to the iscsid.socket unit, and
- The iscsi.service unit
The iscsid.socket unit just encapsulates the socket that the iSCSI
services uses.
The iscsid.service unit "owns" the iscsid iSCSI daemon.
The iscsi.service unit, at the top level, encapsulates iSCSI sessions,
which run on top of the iscsid.service service.
If all three of these new units are enabled, then you get iSCSI as it
was in pre-sysytemd days, i.e. an iscsid daemon running in the
background, waiting to be needed.
If you instead do not enable the iscsid.service, then you get the same
functionality as if it was enabled, except that the daemon is not
started unless needed.
Question 1: What is the best way to ensure these units get enabled
correctly, i.e. iscsid.socket and iscsi.service enabled and
iscsid.service not enabled?
Note that the previous (pre-systemd) open-iscsi package had a file
/etc/init.d/boot-iscsi.early (or something like that), which was always
installed as enabled. I eliminated the need for this seperate
boot-support init file.
I tried to ensure that this package got installed correctly by enabling
the iscsid.socket and iscsi.service units automatically upon
installation, but it looks like there is an openSUSE policy to not
enable any service by default. There also seems to be exceptions, but
both the reasons behind the policy and the exceptions to that policy do
not seem documented.
Question 2: What is the objection to enabling the iscsid.socket service,
since it does not add any resource burden to the system unless it is
needed and used? (Same question for iscsi.service.)
Advice? Answers?
--
Lee Duncan
SUSE Labs
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello all,
openSUSE 13.1 Goldmaster will be released next week, on
Friday 08 November 2013.
Please submit your packages before Friday afternoon (UTC time) to make
sure they will get included in this release. Leaf packages submitted
during the week-end might also get accepted on Monday.
For a quick overview of the openSUSE Roadmap, please see:
http://en.opensuse.org/Roadmap
Thanks,
--
openSUSE Roadmap Reminder
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
On Saturday 12 October 2013 14:19:57 you wrote:
> Hi Sascha !
>
> Is there any possibility we (all python maintainers) discuss our goals
> both python2 and python3 ?
sure, since Juergen joined recently too, I CC'ed everyone. I dunno how you
guys prefer it, we could have an IRC meeting at some point but I guess it's
easier to stay with mails just now. Therefore I added opensuse-packaging@
because that's really where we should discuss things.
> We receive requests sometimes update and/or
> new packages which are Python3 compatible.
>From my PoV, devel:languages:python (d:l:p) and devel:languages:python3
(d:l:p3) are only loosely connected. Of course I tend to update things in both
projects and implement update-alternatives and other features here and there.
So I guess asking submitters to also fix the other package is the simplest
approach. Otherwise, I guess it's about proper tooling.
> Should we allow new packages for devel:languages:python or directly
> impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important
software such as OpenStack. Therefore I wouldn't want to impose anything but
rather ask people.
> I mean we have a lot of packages to maintain, and to do it for both
> python2 and 3 is long and tedius.
In the long run, py3k will gradually replace py2k in openSUSE, that means if
the critical mass is reached and most upstreams moved on, py2k pkgs will
slowly fade from Factory. Meanwhile, some pkg upstreams already stopped caring
for py2k, so their pkgs simply stay with the last working version. Currently
it's more manual work, I agree.
A counter-example is devel:languages:ruby and it's subprojects. It has a very
clever project layout to allow building for several Ruby versions in the same
project. On the other hand, I would argue I know less than 5 people that have
the full picture of the project which effectively reduces contributions on the
project level.
On the other hand, updating a package is in 90% of all cases about downloading
a tarball, adjusting the Version: tag and providing a changes entry. Source
services meanwhile do a pretty good job in automating this. For
Cloud:Openstack:Master (and siblings) we have many source services in use to
automate everything. I started to do just this in devel:languages:go. But
d:l:p is 20x larger so that may not be the way to go. So once I got some time,
I'd be glad to improve py2pack for easier updating. The tricky part is the
automated changes generation as there are a large variety of formats out
there. As always, contributions are welcome :-)
--
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
Hi,
In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the
difference? What is correct naming? (I suppose the last one).
What guidelines/rules should I follow to create CrossToolchain subproject
for yet unsupported arch?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org