rpm vs dep packages

By OK -
Main difference for a package maintainer (I think that would be 'developer' in Debian lingo) is the way package meta-data and accompanying scripts come together.
In the RPM world, all your packages (the RPMs you maintain) are located in something like ~/rpmbuild. Underneath, there is the SPEC directory for your spec-files, a SOURCES directory for source tarballs, RPMS and SRPMS directories to put newly created RPMs and SRPMs into, and some other things that are not relevant now.
Everything that has to do with how the RPM will be created is in the spec-file: what patches will be applied, possible pre- and post-scripts, meta-data, changelog, everything. All source tarballs and all patches of all your packages are in SOURCES.
Now, personally, I like the fact that everything goes into the spec-file, and that the spec-file is a separate entity from the source tarball, but I'm not overly enthusiastic about having all sources in SOURCES. IMHO, SOURCES gets cluttered pretty quick and you tend to lose track of what is in there. However, opinions differ.
For RPMs it is important to use the exact same tarball as the one the upstream project releases, up to the timestamp. Generally, there are no exceptions to this rule. Debian packages also require the same tarball as upstream, though Debian policy requires some tarballs to be repackaged (thanks, Umang).
Debian packages take a different approach. (Forgive any mistakes here: I am a lot less experienced with deb's that I am with RPM's.) Debian packages' development files are contained in a directory per package.
What I (think to) like about this approach is the fact that everything is contained in a single directory.
In the Debian world, it is a bit more accepted to carry patches in a package that are not (yet) upstream. In the RPM world (at least among the Red Hat derivatives) this is frowned upon. See "FedoraProject: Staying close to upstream projects".

Comments

Post a Comment

Popular posts from this blog

HAproxy logging

By OK -
ubuntu@ubuntu:/etc/haproxy$ cat /etc/rsyslog.d/haproxy.conf # Create an additional socket in haproxy's chroot in order to allow logging via # /dev/log to chroot'ed HAProxy processes $ModLoad imudp $UDPServerRun 514 local0.* -/var/log/haproxy-0.log local1.* -/var/log/haproxy-1.log ### keep logs in localhost ## $AddUnixListenSocket /var/lib/haproxy/dev/log ------------------- ubuntu@ubuntu:/etc/haproxy$ cat /etc/haproxy/haproxy.cfg global chroot /var/lib/haproxy user haproxy group haproxy log 127.0.0.1   local0         log 127.0.0.1   local1 notice daemon frontend www     bind 192.168.40.128:8282    # haproxy public IP     default_backend as-backend    # backend used backend as-backend    balance leastconn    mode http  server as1 192.168.40.128:8082 check    # application srv 1 defaults log global mode http option httplog option dontlognull         contimeout 5000    
Read more

tomcat catalina coyote jasper cluster

By OK -
Tomcat Component are Catalina Coyote Jasper Cluster Catalina :  Catalina is the name of the servlet container of Apache Tomcat since version 4.x. Tomcat implements Sun Microsystems' specifications for servlet and JavaServer Pages (JSP), which are important Java-based Web technologies. Tomcat's servlet container was redesigned as Catalina in Tomcat version 4.x. other components of the Tomcat engine are: Tomcat Jasper which converts the code portions within JavaServer Pages into servlets and pass them to Catalina to process. Tomcat Coyote which is an HTTP connector based on HTTP/1.1 specifications that receives and transmits web requests to the Tomcat engine by listening to a TCP/IP port and returns requests back to the requesting client. Coyote :  The Coyote JK Connector element represents a Connector component that communicates with a web connector via the JK protocol (also known as the AJP protocol). This is used for cases where you wish to invisibly integr
Read more

NFS mount add in fstab _netdev instead of default | firewall-cmd --list-all

By OK -
Redhat recommends us to add  _netdev  option for NFS file system in /etc/fstab. So that they can be mounted after starting the networking service. Alternative ways to refer to partitions: Label : LABEL=label Network ID Samba : //server/share NFS : server:/share SSHFS : sshfs#user@server:/share Device : /dev/sdxy (not recommended) Example #1 //192.168.1.134/share_name /mnt/share_name cifs username=server_user,password=server_password,_netdev 0 0 ^ Path to your share ^ Mountpoint ^ Username ^ Password ^ See note A Note A: The  _netdev  options makes sure the mount is only attempted AFTER a network connection has been established. Example #2 10.10.10.1:/vol1/fs1 /data nfs defaults,_netdev 0 0 ============================ [root@localhost ~]# firewall-cmd --list-all public   target: default   icmp-block-inversion: no   interfaces:   sources:   services: dhcpv6-client high-availability ssh   ports:   protocols:   masquera
Read more